Work environments in software development

[AnalyticalEngine]

Hello esteemed ERE forum. I am a software developer with ten years of experience looking for a new job and I have a question for my fellow developers here.

Specifically, what types of environments have you worked in and which ones did you like? I have worked basically only in corporate environments that are some variant of Agile micromangement hell, but I'm interviewing with a tech startup right now that seems to be the polar opposite of this. There's this huge focus on being "lean" and on individual engineers and their productivity. On one hand, I think this would be great to escape the bureaucratic torment of corporate Agile, but on the other hand, the Kafkaesque, incredibly slow nature of corporate Agile makes it easy to do all my work in a few hours a week then have time for other things. My concern with a startup is that, while the work maybe more interesting and I would enjoy more challenging engineering problems, that it might also consume my life.

So what experience do you all have working in different work environments in software? Which was your favorite and why?

[zbigi]

I've worked in many environments (I'm a consummate job hopper, which is why contracting suits me), and basically the only one I liked was when I was the one and only developer in a researchy startup. Finally, I had authonomy over how I do my work. I didn't need to justify and explain minute choices I made to other developers (I hate code reviews), could experiment etc. This was probably as good as good the work can get.

I had extreme amounts of luck in landing such job - I was uniquely qualified for it (I've just spent 2+ years of my own time working on something similar) and, by sheer luck, got contact to a guy who was just launching a startup in this area - likely only one in the world. Also, the guy was an awesome human being - very smart, but also very considerate, and not interested in profit above all else (I felt like he was more excited by verifying his ideas than by making money off them). He gave me a ton leeway, and vehemently defened me from investors, who kept asking questions why exactly are we paying this remote Eastern European guy $80/h.

Not surprisingly, the startup folded after we run out of funding, and I was working your regular jobs ever since. Compared to that experience, the jobs were pretty much extremely similar. Code reviews, agile ceremonies, large preexisting code bases, boring domains, little autonomy. The pressure in startups was noticeably higher (but nothing off the charts - perhaps the ZIRP made startups relaxed about money and timelines back then), the bureucratic and agile nonsense was much higher in corporate (startups didn't do sprints for example, as they add management overhead). But, at the end of the day, they were all essentially the same jobs.

[Slevin]

I didn't need to justify and explain minute choices I made to other developers (I hate code reviews), could experiment etc.

This would be a huge red flag for me in the hiring process, but I will agree that some people overdo it in code reviews in terms of style, etc. Companies need to have at least component / project wide style rules, comment rules, etc, so that the next person can come in and understand the code, make changes, etc. The maintainer is more important than you (the writer), as they will be in the code much more than you will over the next 10+ years. Also, everybody makes mistakes. A second pair of eyes will help catch these (provided you are doing small PRs, and not eye bleedingly long commits, which are another bad thing).

I worked for huge corporate company (120k employees, 68B rev), a small company (140ish employees, private so don't have rev numbers) that grew to medium sized while we were there, and now work at a medium large org (1000ish employees, >500M revenue).

Best work environment IMO is small to medium sized company (50 - 500 employees) in terms of balance / autonomy, etc. Some of these will still use "Agile" etc, but many of them do the dressings with none of the sacrifices. Basically go for somewhere where you have a work queue that you pull from, get the work done, get it reviewed, get it merged, move onto the next one. Yes there will be deadlines sometimes, but there shouldn't ALWAYS be end of the world deadlines (if everything is incredibly important, nothing is) / burning yourself out for no reason. You also don't want to be the only person around who knows how anything works, or you will be the one who gets called on when anything goes wrong (read middle of the night). the 1000 person company can also be nice, but there's more corporate BS, will be more nonsense going on, etc.

Also try and make sure you have more senior people in the company that you work closely with and can learn from. Especially at 10 years in. A big piece missing from a lot of software jobs is having people actually help you out when you need to and who you can learn from / have actual interesting work conversations with on merits, etc. I think this is generally underrated in the software world.

[jacob]

Best work environment IMO is small to medium sized company (50 - 500 employees) in terms of balance / autonomy, etc.

Interestingly, mid-range is also the best choice in academia. If you have a choice in supervisor, pick the associate professor. The full professor is likely stale from research and too bogged down by administration. The assistant professor is too focused on getting tenure and using/ignoring you to their own ends or lack thereof.

It all comes back the S-curve: https://earlyretirementextreme.com/bett ... urves.html

Then again, it also depends on what the employee is looking for. Not everybody wants "meaningful work" from their job. Some just want the "bennies". Others just want to "be told". The mid-range is a good generalized compromise between freedom and opportunity.

[zbigi]

This would be a huge red flag for me in the hiring process, but I will agree that some people overdo it in code reviews in terms of style, etc.

That's why I don't bring it up during the hiring process Everybody has parts of the job they hate - for me it's this constant need of communication over details. It sucks the fun out of the job. It may be exacerbated by the fact that I work in Scala, which is very expressive and allows for multitude of approaches to any problem - which many people feel need to be discussed before we go ahead with the PR.

Companies need to have at least component / project wide style rules, comment rules, etc, so that the next person can come in and understand the code, make changes, etc. The maintainer is more important than you (the writer), as they will be in the code much more than you will over the next 10+ years. Also, everybody makes mistakes. A second pair of eyes will help catch these (provided you are doing small PRs, and not eye bleedingly long commits, which are another bad thing).

I get that and maybe even agree with this (i.e. if I had a company making relatively simple and boring business software, I'd probably mandate the same approach), I'm merely saying I don't like it.

[AnalyticalEngine]

I suppose it makes sense that midrange tends to be best because it has that balance between being small enough that you don't get lose in the process, but big enough that not everything is dumped onto you and you have an opportunity to network. Although I've found with software, engineers are not overly numerous compared to other departments. So the question is if the ideal is 50 - 500 engineers or total employees. I notice that a company with 50 employees will have maybe only 10 of them be actual software staff.

One thing I have noticed about larger firms, especially if they aren't primarily software-focused, is that they run the projects for the "average" engineer, which is why the Agile overhead is so painful and you can get away with one hour of work a day. The smaller places seem to put more effort into hiring the right people. That makes sense because if you need to hire 1,000 engineers, you are going to assume everyone is average and hire accordingly. Whereas if you only have a team of 8 people, you need to make sure each of those 8 people are high quality.

Which is the main thing I'm looking for here--higher quality coworkers and less pointless Agile overhead. Of course, there will always be process, which is fine when it makes the project run smoothly, it's just when I spend an entire two weeks in meetings everyday scheduling out all the work for the next quarter down to the hour that I want to tear my hair out.

Also mentoring is a big thing. Especially with 10 years of experience, I'm finding it extremely easy to plateau at this point in my career. I'm finding that my professional network and opportunities for mentorship are two major things I've been missing in the average corporate gig.

[jacob]

One thing I have noticed about larger firms, especially if they aren't primarily software-focused, is that they run the projects for the "average" engineer, which is why the Agile overhead is so painful and you can get away with one hour of work a day. The smaller places seem to put more effort into hiring the right people. That makes sense because if you need to hire 1,000 engineers, you are going to assume everyone is average and hire accordingly. Whereas if you only have a team of 8 people, you need to make sure each of those 8 people are high quality.

Yes, the bigger the system gets, the more important it is choose between "fixing stupid" or "dealing with the average" or "enjoying the company of smart people". Therein lies the problem for society. Whereas individuals can skirt around it, society is ... has ... will .. somehow ...

[delay]

There's this huge focus on being "lean" and on individual engineers and their productivity.

"Lean" can be a very corporate term. It is associated with the Toyota Production System made famous by books like The Toyota Way (well worth reading.) The Six Sigma methodology known for its Green and Black Belt certifications added "Lean" to become "Lean Six Sigma".

So what experience do you all have working in different work environments in software? Which was your favorite and why?

In terms of work, a team with skilled colleagues at a medium sized company without project managers was my favourite.

In terms of hours required, maintaining legacy software after a corporate takeover was a dream job.

Working as a temporary developer for 1 day to 3 week assignments taught me a lot of practical things.

Some people like jobs that others hate. While you work your job changes, your colleagues change and you change. Some jobs are not what they seem. It's a wonderful world.

[Slevin]

I suppose it makes sense that midrange tends to be best because it has that balance between being small enough that you don't get lose in the process, but big enough that not everything is dumped onto you and you have an opportunity to network. Although I've found with software, engineers are not overly numerous compared to other departments. So the question is if the ideal is 50 - 500 engineers or total employees. I notice that a company with 50 employees will have maybe only 10 of them be actual software staff.

For me it was ~100 engineers, 150 non engineers. The higher this ratio, the more a company is catered to tech and the more nice stuff* the engineers have and the more they are valued in the company. I would personally want 50-300 engineers. People who want everything "their way" will want that number diluted, as @zbigi pointed out above. The more engineers, the more compromise, the bigger communications problems, etc. Eventually adding more people to working on a subset of software makes it slower, as the coordination costs get too high. You want to be in the sweet spot (teams of 6 or smaller including project / product management, ideally teams of 4-5 developers IMO).




*in a stupid way.

[guitarplayer]

it's just when I spend an entire two weeks in meetings everyday scheduling out all the work for the next quarter down to the hour that I want to tear my hair out.

Is there a textbook for learning about this process? This is a serious question, I work with this from the outside requesting things ultimately done by data engineers, I would like to have a better understanding of the process there in order to be less of a pain.

[AnalyticalEngine]

@guitarplayer - What you're going to want to look into is the scaled agile framework (or SAFe) because that's the management framework from anywhere I've worked that does these awful two week planning sessions. I have found different organizations all use SAFe a bit differently, though, so you may find there's variation. The whole point of SAFe is that it's supposed to "scale" "Agile" for extremely large firms because "Agile" was designed for small teams. But in practice, I have found SAFe wastes a lot of engineering time by trying to make every engineer aware of every little thing, which does not work when you have a very large project. So much so that I actually consider a job that uses SAFe to be a red flag because it ends up being the worst of "Agile" and the worst of "Waterfall."

Mercifully, where I work now stopped doing the two week planning sessions (it's called "PI planning" in SAFe lingo.) I always found these sessions to be a waste of time because software development is very often an exercise in managing unknowns, and it's difficult to predict how a project is going to go weeks in advance.

[zbigi]

@AnalyticalEngine I've worked in an large org that did SAFe, but luckily our PI Plannings were 2 or 3 days long - so it's not always a two week long ordeal. Like you said, they felt pretty irrelevant for engineers, who mostly treat it as an opportunity to socialize and do nothing for the duration (as one of my colleagues put it, after an exalted opening presentation from the head honcho, "that was pretty good, unfortunately towards the end the battery on my phone died and I couldn't finish a level in a game I was playing").

BTW, my not entirely unrelated observation is that in a white collar career, the core part of your job is pretending that you care (whereas, in a blue collar job, nobody cares if you care, you just need to make 20 burgers per hour). Part of the difficulty of being in management is that it's a high visibility position - a lot of people have eyes on you a lot of the time (as you spend a lot of time in meetings). As such, it is much harder to pretend that you care in a believable way, and hence it requires high intelligence and a bit of skill in performative arts.

[AnalyticalEngine]

my not entirely unrelated observation is that in a white collar career, the core part of your job is pretending that you care (whereas, in a blue collar job, nobody cares if you care, you just need to make 20 burgers per hour). Part of the difficulty of being in management is that it's a high visibility position - a lot of people have eyes on you a lot of the time (as you spend a lot of time in meetings). As such, it is much harder to pretend that you care in a believable way, and hence it requires high intelligence and a bit of skill in performative arts.

This checks out with my experience. In the job I'm interviewing for, the recruiter wanted to stress to me that they really wanted to hire someone who was "passionate" about their product, and all the interviews have centered around me largely finding a way to preform this because all of the interviews have been "informal conversations." Luckily, I'm fairly good at this and have found interviewing is usually easy for me as a result.

My current role has gotten a lot more reasonable with how they do SAFe, but at my last job, it was a mess because there were like seven layers of management between me and the CEO, so everything management did was a performance for the layer above them. Hence, we'd get the awful PI planning sessions where you'd get feedback about your lack of "engagement" if you didn't act excited for the entire two weeks. This was obviously because the upper management was watching the lower management during these events, so the whole thing was a spectacle by lower management that required the engineer's participation. I find engineers don't really excel at these management games because it very rarely involves any benefit to you and a lot of engineers are, shall we say, very heavily skewed Te with a complete lack of Fe. And perhaps unsurprisingly, about half the engineering team quit where I used to work.

Fortunately, there are a lot of software jobs out there, so I now try to screen for these things during job interviews. Usually asking them how they do planning and releases will reveal a lot about corporate leadership dynamics. I think a good job is one where you can really focus on engineering and the project management overhead facilitates development instead of getting in its way/slowing it down.

[jacob]

The joy/meaning of SD:orange...
(winning a game of climbing a ladder w/o offending the next layer up)

[Scott 2]

Is there a textbook for learning about this process? This is a serious question, I work with this from the outside requesting things ultimately done by data engineers, I would like to have a better understanding of the process there in order to be less of a pain.

The challenge you'll run into - no organization implements a by the book process. Inevitably they are special and need exceptions, often breaking key principles behind the original canned process.

For a straightforward introduction to lean software processes, I like Dominica Degrandis's book Making Work Visible.

Every few years, there will be a new canned process. Change agents cannot make money unless they challenge the status quo. Dig away the layers and it's the same ideas in new wrappers. Fancy words around systems thinking.

[jacob]

Fancy words around systems thinking.

Most humans don't yet grasp it naturally. As long as that's the case, it needs to be presented over and over in a way that people can relate to. Whether that's a specific language, a specific metaphor, or a specific relatable presenter ... It is what it is #process.

[guitarplayer]

Today I was for the second time taking part in a Sprint Demo in the role of a 'stakeholder'. I had no idea what this is about so the first time around I used the time to query and brainstorm some ideas. At the beginning of today's one, a colleague from my team enlightened me off the record that these sprint demos serve the function of a platform to say 'thank you' to the engineers.

I will never be natural for this sort of environment (read: corporate), I appreciate having people talking to me off the record.

[Scott 2]

these sprint demos serve the function of a platform to say 'thank you' to the engineers.

This is a great example of losing the underlying principles. The entire point of this ceremony is shorter feedback loops. We know the wrong thing will be built. The goal is to uncover corrective actions before business value is lost. The critical component? FEEDBACK!!!

Not to say your colleague is incorrect about your political environment. Getting the broader stakeholder pool engaged in lean principles is a hard problem. That's why we end up with distorted processes, that only serve to add overhead and impose suffering.

[guitarplayer]

Yes, I think purpose there being feedback would make sense in the modernist framework while my colleagues comes from a more post modern stance. I am okay with either.

[Egg]

Yes, I think purpose there being feedback would make sense in the modernist framework while my colleagues comes from a more post modern stance. I am okay with either.

I've worked in 3 software development roles so far and in every case it's been about feedback, and we've regularly made changes based on that feedback. Agree with what's already been said that in your particular organisation that's not the done thing but I think your organisation is the exception rather than the rule.

As for the OP and ensuing comments on this thread, it's clear to me that it's all as much a function of the individual developer as of the organisation - it's how closely the preferences of each fit together. I personally love the "safe" feeling of, let's be honest, bureaucracy that comes with agile ceremonies, code reviews, extensive automated tests and whatever else we do that a scrappy, hungry startup doesn't see any value in. I understand why many people don't like it - especially natural high performers who feel it holds them back - but for me it's great. Seems that OP sees some pros and cons, so just a question of weighing them up based on your personal value framework