|
Depending upon the resources available to you it might be a "let's see how well this person can scrounge together crap in this hellhole of a workplace" hazing scenario or people simply expect you to speak up and it's more passive-aggressive culture that's pervading. I'm more familiar with the former as an excuse for management to basically not do anything except bureaucratic busywork that consumes their lives instead of oh... managing people and processes, but I just suck it up and learned to talk to the right people and to get to the right resources to help me make a non-catastrophic project. I've heard of several projects where people tried to speak up for months or even years while they had meetings to figure out what they should be doing when they have zero access to anything, and it's hard to say if that kind of complicated bureaucracy is the fundamental problem without more info. Agile is oftentimes misused when you're really looking for "lean" principles that are even broader and apply across more than just software (I've never heard of Agile being used anywhere other than software dev, and it was a Bad Idea when I led an ops team for sure because we couldn't commit to anything ever). That is, lean is to do the minimum you need to get to a reasonable set of expected results as you go along because your project could just get cancelled for random reasons anyway so long-term planning has only so much benefit and is only of value when you have sufficient stability (and really, inertia) to consider sunk cost problems and strategy.
|
#
?
Jun 5, 2016 18:47
|
|
|
|
| # ? May 11, 2024 23:48 |
|
|
necrobobsledder posted:Agile is oftentimes misused when you're really looking for "lean" principles that are even broader and apply across more than just software (I've never heard of Agile being used anywhere other than software dev, and it was a Bad Idea when I led an ops team for sure because we couldn't commit to anything ever). That is, lean is to do the minimum you need to get to a reasonable set of expected results as you go along because your project could just get cancelled for random reasons anyway so long-term planning has only so much benefit and is only of value when you have sufficient stability (and really, inertia) to consider sunk cost problems and strategy.
|
|
#
?
Jun 5, 2016 19:27
|
|
|
necrobobsledder posted:Depending upon the resources available to you it might be a "let's see how well this person can scrounge together crap in this hellhole of a workplace" hazing scenario or people simply expect you to speak up and it's more passive-aggressive culture that's pervading. I'm more familiar with the former as an excuse for management to basically not do anything except bureaucratic busywork that consumes their lives instead of oh... managing people and processes, but I just suck it up and learned to talk to the right people and to get to the right resources to help me make a non-catastrophic project. I've heard of several projects where people tried to speak up for months or even years while they had meetings to figure out what they should be doing when they have zero access to anything, and it's hard to say if that kind of complicated bureaucracy is the fundamental problem without more info. Sorry, I may have misrepresented the situation. I was contacted by marketing to put together an application for them, and I'm the only one involved - I'm the one expected to handle project management and the like, I'm realizing now. I'm not reporting to anyone except my (in-company) client. And I don't think there's hazing going on, it's not that kind of culture.
|
|
#
?
Jun 5, 2016 19:36
|
|
|
Pollyanna posted:Sorry, I may have misrepresented the situation. I was contacted by marketing to put together an application for them, and I'm the only one involved - I'm the one expected to handle project management and the like, I'm realizing now. I'm not reporting to anyone except my (in-company) client. And I don't think there's hazing going on, it's not that kind of culture. Vulture Culture posted:I think the Bad Idea part is changing, but it took ten years of tooling developments from the Cfengine days through Docker for me to finally be able to run ops competently across an Agile product.
|
|
#
?
Jun 5, 2016 20:37
|
|
|
necrobobsledder posted:So you need to set expectations and requirements and ask the right questions before writing a single line of code or asking for a single account. Start with the basic technicals, work up to broader questions or concepts, and ask those questions to your stakeholders. Urgency, timeline, and impact of the project are good starters to clarify at least and it'll tell you if you're being thrown under the bus right away if whoever you're working with is somewhat honest. If you're alone, I'd venture to say that you are almost certainly looking at taking existing software and hacking it up and customizing somewhat as your project because actually coding it while doing management BS is something that I've almost never seen anyone do without working 70+ hour weeks for the duration of a project. I am working with the client to get basic requirements on what the users will want, and trying to present weekly demos of the currently existing product (which is disappointingly little so far). I'm used to working under a project manager and having someone else tell me what I need to get done, so doing this all alone (especially from scratch) is pretty daunting. Do you mean to say that this is a bad position to be in? Regardless, I may have bitten off more than I can chew, especially since I'm doing this in a framework I'm new to and that is in a different paradigm than Rails. 
Pollyanna fucked around with this message at 22:18 on Jun 5, 2016 |
|
#
?
Jun 5, 2016 22:12
|
|
|
necrobobsledder posted:For me ops means "traditional ops" since the whole "devops" term is popular and has a very different workflow and set of connotations and where the term "configuration management" evokes vendors, not technology like cfEngine, fai, Puppet, Chef, Docker, etc. That is, ops means you're thrown a bunch of software products over a wall from vendors typically outside the company and you act as computer janitors with minimal feedback to the products you're stuck supporting and keeping up a bunch of black or gray boxes with a pretty inflexible n tier architecture almost always (I've never been in a place where they treated a Cassandra or Hadoop cluster the same way they treat an SAP, Oracle, or Exchange cluster under the yoke of ITIL processes, for example). Almost no traditional operations person I've worked with has worked with Agile intimately before I showed up and started doing things "like those software people do." Ops for a software company's SaaS product, for example, is much easier to sync together with any operations team because schedule sync is much easier than with an n-vendor, m-project ADHD approach to tasking for operations people.
|
|
#
?
Jun 5, 2016 23:22
|
|
|
Pollyanna posted:I'm working on a project for the marketing division at work in an internal contractor-like setup. Meaning, I have demos and requirements meetings with my contact in marketing, and I work on the application on my own (work) time. I've learned that I am completely miserable at managing a project on my own, both for requirements and for time Read the Software Project Survival Guide by Steve McConnell
|
|
#
?
Jun 5, 2016 23:57
|
|
The project is not at the level of completeness I had hoped for by the next demo (tomorrow), there's no wiki or project page or anything, and I feel like I have no idea what I'm doing. I'm worried for the long term health of this project, even with it being relatively small.
|
rt4 posted:Read the Software Project Survival Guide by Steve McConnell This book looks pretty good. I'll pick it up. I just hope I don't have to rely on it more than once...
|
|
#
?
Jun 6, 2016 02:19
|
|
|
You could also tell your stakeholders that you don't have anything interesting to demo yet this week, but if they'd like to see the hello world page on your whatever as you begin working to come on by, and that future weeks will be a lot more useful.
|
|
#
?
Jun 6, 2016 04:39
|
|
|
Volmarias posted:You could also tell your stakeholders that you don't have anything interesting to demo yet this week, but if they'd like to see the hello world page on your whatever as you begin working to come on by, and that future weeks will be a lot more useful. Isn't a demo supposed to showcase a fully working product, though? I knew I wouldn't have a fully working product in a week, obviously, but it kinda goes against the "prototype like crazy" mantra.
|
|
#
?
Jun 6, 2016 13:06
|
|
|
Pollyanna posted:Isn't a demo supposed to showcase a fully working product, though? I knew I wouldn't have a fully working product in a week, obviously, but it kinda goes against the "prototype like crazy" mantra. If you are using demo in the agile sense, it's mostly just to show off what work you accomplished over the last sprint to the stakeholders. If all you have is a test server stood up and a hello world home page, then so be it.
|
|
#
?
Jun 6, 2016 13:18
|
|
|
Pollyanna posted:Isn't a demo supposed to showcase a fully working product, though? I knew I wouldn't have a fully working product in a week, obviously, but it kinda goes against the "prototype like crazy" mantra. In my experience, a demo is more like a semi-interactive GUI that might not have very much behind it. You probably shouldn't even let the client touch the controls. Just walk them through some likely user stories. As they watch, they will gather information that they can use to tell you if you're still on the right course.
|
|
#
?
Jun 6, 2016 14:10
|
|
|
Not all demos are actually customer-facing - they can be meant for internal stakeholders that are concerned about your progress and for you to demonstrate that you know what you're doing. It might just be a status meeting, but up-front planning and organization is appreciated usually. If you have written design and requirements documents along with some planning, summarizing them in slides can be a sufficient "demo" of progress. This can quickly reveal all sorts of things about how seriously people are taking your project as you watch their reactions. I've seen way too many presentations where the speaker doesn't realize the audience is literally falling asleep and to move on quickly - don't be that guy.Vulture Culture posted:That aside, the whole reason DevOps exists is because there was a massive impedance mismatch between Agile-style development and waterfall-style operations.
|
|
#
?
Jun 6, 2016 15:01
|
|
|
Pollyanna posted:I'm working on a project for the marketing division at work in an internal contractor-like setup. Meaning, I have demos and requirements meetings with my contact in marketing, and I work on the application on my own (work) time. I've learned that I am completely miserable at managing a project on my own, both for requirements and for time Inexperience Looks like u getting hosed by poor mgmt
|
|
#
?
Jun 6, 2016 15:18
|
|
|
nm
pigdog fucked around with this message at 16:43 on Jun 6, 2016 |
|
#
?
Jun 6, 2016 16:39
|
|
|
necrobobsledder posted:I haven't seen operations go through any sort of project management paradigm that could even be described as waterfall due to operations people oftentimes serving as L2/L3 helpdesk that organizations usually have a separate team that handles projects while another team handles day-to-day interruptions and toil (this is usually the team that gets outsourced I've found because they can't retain decent people to toil and the work requires far less talent to successfully accomplish). We both know that this is probably a Bad Idea as well because it won't scale, but I don't think most of the Fortune 100 knows anything about effectively scaling teams and software with infrastructure in the first place. Vulture Culture fucked around with this message at 17:42 on Jun 6, 2016 |
|
#
?
Jun 6, 2016 17:39
|
|
|
smackfu posted:OMG, when agile meets an entrenched DBA group, so painful. Why does the dba care the purpose of the loving columns? How many rows are in this table? e: This thread makes me value the simple processes we have at work.
|
|
#
?
Jun 7, 2016 04:29
|
|
|
KoRMaK posted:
Praise be. A PM tried to schedule a 6 hour chartering meeting with the infrastructure team. Our boss said no this Isn't right and the PM was like I don't care. Boss sent out 4 hour random meeting blocks throughout the team for 'solo focus' that made the meeting unable to be scheduled for the next month or so.
|
|
#
?
Jun 7, 2016 04:36
|
|
|
Virigoth posted:Praise be. A PM tried to schedule a 6 hour chartering meeting with the infrastructure team. Our boss said no this Good god, these uncle bob talks that I've been marathoning make a lot more sense now https://www.youtube.com/watch?v=BSaAMQVq01E&t=2736s
|
|
#
?
Jun 7, 2016 04:42
|
|
|
I work at one of those dinosaur companies that is slowly fading, and desperately trying to cling on. Manager at a meeting today: "SQL? Isn't that like one of those 70s technologies? Wouldn't it be more agile if we use NoSQL?" This was for a project estimated to generate 1M records per month, hah. The rest of the company does story points and all that bullshit but our little group has only adopted standups. Our standups regularly run 20 minutes for 4 developers if the manager attends (he always attends). We end up talking about old TV shows he likes or whatever. Despite that I actually like the place a lot and I'm having a hard time wanting to look around even though I know a VERY LARGE LAYOFF is coming.
|
|
#
?
Jun 7, 2016 05:04
|
|
|
My Rhythmic Crotch posted:This was for a project estimated to generate 1M records per month, hah. That's not really an argument for using SQL. The manager's argument for not using SQL is obviously worse, but still.
|
|
#
?
Jun 7, 2016 09:15
|
|
|
KoRMaK posted:I dont even know what the gently caress this poo poo means. Descriptive names? You mean the name I gave them, like "first_name" or "my_butts_measurement"? Physical data model vs logical data model? What the hell is the difference? I don't really know, to be perfectly honest. I think the logical one might be database agnostic.
|
|
#
?
Jun 7, 2016 12:21
|
|
|
Malcolm XML posted:Inexperience Yayyyyyyyyyyyyyy I mean, it's not awful, but it's not my favorite setup. I'll just try as hard as I can for this part.
|
|
#
?
Jun 7, 2016 12:38
|
|
|
Messyass posted:That's not really an argument for using SQL. The manager's argument for not using SQL is obviously worse, but still. Serious question - when does it matter? When is NoSQL better over SQL?
|
|
#
?
Jun 7, 2016 13:19
|
|
|
KoRMaK posted:When is NoSQL better over SQL? NoSQL is for applications that need a very high insert rate and don't need to use the data again after it's been inserted
|
|
#
?
Jun 7, 2016 13:46
|
|
|
rt4 posted:NoSQL is for applications that need a very high insert rate and don't need to use the data again after it's been inserted That raises further questions, such as what's the point of storing data you'll never see or use again? And in what case would you pull data back out?
|
|
#
?
Jun 7, 2016 13:55
|
|
|
I've found you go nosql under pretty much three situations 1. You don't have a fixed schema 2. You need to scale something to google or facebook size 3. You want to use a cool new technology Most of the time, for most workloads, relational DBs are superior.
|
|
#
?
Jun 7, 2016 14:02
|
|
|
http://arstechnica.com/information-technology/2016/03/to-sql-or-nosql-thats-the-database-question/ Really great analysis of use cases. They also have a related article that looks at use cases for specific NoSQL dB's. My favorite example from the one above though is a company that digitizes transit schedules. Since no two organizations in the US have the same format for their schedule, SQL is right out the window.
|
|
#
?
Jun 7, 2016 14:18
|
|
|
You use a specific non-RDBMS database when you have already hit or are guaranteed to hit a specific case where no cost-effective RDBMS will meet your needs long-term and you can articulate the need into a requirement that your new solution must provide. Normally it's because of CAP Theorem based reasons where you're willing to sacrifice one for some form of scale or because schemas are not going to work for you. Some people find solutions like MongoDB perfectly fine for the sake of prototyping stuff faster because you don't need to think about database migrations anymore, but you should have a good idea of what you want from your persistence layer before reaching for anything other than Postgres close to the beginning. I like to think that Postgres and SQL in general is a lot like Unix - "Those who don't understand RDBMS are doomed to re-invent it." I think most people pick Non-SQL persistence layers because they are Bad At SQL, don't want to deal with static schemas and the development-deployment issues they can cause (read: database migrations and schema changes), and have some vaguely researched use cases. On the other hand, nowadays you can run Postgres as a schema less database based upon JSONB representations if you can get your hands on Postgres 9.4 at least.
|
|
#
?
Jun 7, 2016 15:24
|
|
|
KoRMaK posted:I dont even know what the gently caress this poo poo means. Descriptive names? You mean the name I gave them, like "first_name" or "my_butts_measurement"? Physical data model vs logical data model? What the hell is the difference? I'll take some guesses. Logical vs physical data model I would interpret as the high level meaning of the columns (e.g. this is a unique/opaque identifier, this stores a user-provided description string) vs roughly or specifically the SQL schema (e.g. this will be an autoincrementing unsigned 64 bit integer, this will be a varchar(255) with utf8 character encoding) As for why the DBA cares about the purpose of the columns, I'd imagine that's so that they can gauge/verify various aspects of tuning and provisioning that are relevant to them (as well as sanity checking): it is helpful to know how you anticipate the dataset growing, how it will be accessed, etc. To be sure, the DBA scenario smackfu laid out sounds unpleasant, but it's not unreasonable for the folks managing the databases to be involved and have input on how those databases are used. In fact, it's better not to just have devs throw a schema over the wall at the DBAs; in my understanding of the horribly overloaded term devops (please please please don't let this start an argument about what devops is), you *want* that involvement.
|
|
#
?
Jun 7, 2016 15:28
|
|
|
KoRMaK posted:Why does the dba care the purpose of the loving columns? It's generally an X-Y problem. What the DBMS supports something more efficient than what the developer asked for? If I said to a DBA that I needed a string column but neglected to inform them that what I was storing was XML or JSON or something structured like that then what will probably happen is the resulting schema won't be optimal for storage and the developer will probably write some stupid loving LIKE query which would table scan and absolutely murder performance. quote:How many rows are in this table? Knowing how large the table is going to get would be very important for data partitioning and disk allocation. Knowing how frequently it's going to be accessed would be important for knowing what media to store the data on...stupidly expensive high availability SAN or less speedy but less costly disks? To sum up, it's just possible that a good DBA may know something about DBMSes that even a good developer doesn't 
|
|
#
?
Jun 7, 2016 15:57
|
|
|
KoRMaK posted:That raises further questions, such as what's the point of storing data you'll never see or use again? And in what case would you pull data back out? It's not that you'll never use it, but that you'll rarely use it or query it like you would in a relational DB . Audit logs for example. Or document storage. Don't get me wrong, SQL would still almost always be my default choice as well, but it's not a bad idea to at least think about the particular problem you're solving. Even within one system you might use two different solutions side by side (as in CQRS). You might make a different choice if you have 1000 commands for every query than if you 1000 queries for every command.
|
|
#
?
Jun 9, 2016 13:47
|
|
|
KoRMaK posted:Serious question - when does it matter? When is NoSQL better over SQL? It's great for toy Web Apps. Just json.stringify whatever records you want to store and it's entirely possible they'll come back as json again. Might take 5 minutes to make a functioning backend.
|
|
#
?
Jun 10, 2016 23:36
|
|
|
So, it came kind of down to the wire, but we did successfully complete the important projects that were dumped on me and a colleague after our coworker completely dropped the ball on them. So, yay for that. In other news, after 10 years of being a lowly code monkey(a position I quite enjoyed thank you), I am now the active manager of a team of offshore developers(some of which used to work onshore so I already knew them), and am also going to be leading an onshore team on another project. All of this happening in a one month period of time. This will be accompanied by a promotion and raise as soon as the new head of IT finishes with his current project of consolidating and defining the different positions in the department, as all promotions have been put on hold until that has been done. So yeah, that happened...and honestly I kind of feel in over my head for the first time since I joined the software development world. Whee.
|
|
#
?
Jun 17, 2016 18:58
|
|
|
Khisanth Magus posted:So, it came kind of down to the wire, but we did successfully complete the important projects that were dumped on me and a colleague after our coworker completely dropped the ball on them. So, yay for that. My condolences.
|
|
#
?
Jun 17, 2016 19:03
|
|
|
Khisanth Magus posted:So, it came kind of down to the wire, but we did successfully complete the important projects that were dumped on me and a colleague after our coworker completely dropped the ball on them. So, yay for that. Enjoy never coding again.
|
|
#
?
Jun 17, 2016 19:16
|
|
|
Khisanth Magus posted:So, it came kind of down to the wire, but we did successfully complete the important projects that were dumped on me and a colleague after our coworker completely dropped the ball on them. So, yay for that. Lmao
|
|
#
?
Jun 17, 2016 19:19
|
|
|
Khisanth Magus posted:In other news, after 10 years of being a lowly code monkey(a position I quite enjoyed thank you), I am now the active manager of a team of offshore developers(some of which used to work onshore so I already knew them), and am also going to be leading an onshore team on another project. You can get a jump on your new role by blocking out 8:30-18:00 on your calendar in 60 minute intervals, Monday through Friday. Just use the placeholder 'meeting'; you can fill in the specifics as you learn them.
|
|
#
?
Jun 17, 2016 19:58
|
|
|
B-Nasty posted:You can get a jump on your new role by blocking out 8:30-18:00 on your calendar in 60 minute intervals, Monday through Friday. Just use the placeholder 'meeting'; you can fill in the specifics as you learn them. As an individual contributor trying to write software in a large corporation, this is what I already have to do.
|
|
#
?
Jun 17, 2016 20:16
|
|
|
|
| # ? May 11, 2024 23:48 |
|
|
Khisanth Magus posted:This will be accompanied by a promotion and raise as soon as the new head of IT finishes with his current project of consolidating and defining the different positions in the department, as all promotions have been put on hold until that has been done. 
|
|
#
?
Jun 18, 2016 17:58
|
|
