I think the bad started for me (long ago) when the Microsoft style management and so-called MS best practices began to conquer the PNW.
In the late 90's a company I was in started driving to an exit. First they hired an ex-MS Group Program Mgr, whatever that means. Next, came tons of PMs pulling one or two devs into their projects/features. Doing it the MS way I guess (at least the MS way back then).
I was a manager, I refused to dole out my team members to PMs -- everything my team did was run through me. I don't even think I let them enter individual devs into their project plans. Just the team.
This worked well for us (my team) because I knew their capabilities, interests, family commitments, likes/dislikes, etc. I could adjust resources as needed to meet the team commitments. We had successes and failures as a team.
PMs who tried put pressure on my devs behind my back would really catch it from me.
My management style wasn't any new idea, it was what we did in the Army. Assign a team a task, then the team leader ensures the task is completed by the team.
It was a good time, we were the only real team in the place as the other managers embraced the MS way of doing things.
At end (right before dotcom bust) the company started doing some Agile-lite with two-week release cycles absent stories, standups, etc. I did like that enough to put it place at the next company I worked at.
I did get burned out though, mostly because I didn't want deal with what the industry had become as the last startup I was at petered out.
I still love programming but not enough to do it in modern shop.
This rings true. It's probably why I have always had a tendency to look sideways at these efforts to turn everyone into a coder. I get it: there's demand, opportunity, etc. But, for me, there's always been a cynical element of devaluing actual coders to it.
The stuff you're talking about regarding your management approach almost seems like a relic from a bygone era at this point. So many companies now allow the process to manage devs. PMs back then frequently over-focused on the work vs. people, but even many of them have been replaced with some version of a scrum master with an even more relentless focus on the never-ending storyboard. They're driving the work over people approach without apology because it's what the process demands.
This is not to say it's 100% the case across all companies. But, there's very much an inhuman element to the process that has manifested to some degree in nearly every place that employs agile.
> Likewise, with CI/CD. And don't get me started on the monkey-work that is TDD. You might argue that it improves code quality. But, it's hard to make the case that it improves job satisfaction. If you move more work from the creative, problem-solving bucket into the busy-work bucket, the result will not be personal fulfillment.
> Does agile increase productivity for companies? Sure. But, it comes at a high cost that's mostly paid by devs.
I agree wholeheartedly with you. I'm by no means suggesting we move back to waterfall, but I am really enjoying the work I'm doing more and more of lately: embedded. Nominally it's a sort of Agile-type workflow (Kanban-ish), but because there's hardware design and manufacturing in the loop, things get planned out early and the multi-month plan doesn't change very much. New algorithm ideas pop up and get scheduled, new ways of doing sensor filtering pop up and get scheduled, but the direction of the wind doesn't change at the start of every "sprint". There are no sprints, just a prioritized/sequenced task list that gets reevaluated periodically.
(Plus, I get to go back to my old days C-hacker roots. The thing builds with a Makefile and spits out a ~32kB binary that gets flashed onto the device.)
I've always thought this was a red herring for scrum people to smack dissenters with. I've never done a strict waterfall with unyielding changes. Before agile, we would do 3 month release cycles. We prioritized what we wanted to get done in the 3 months and what we didn't get finished fell off to the next cycle. This was done in BigCompanyYou'veHeardOf and SmallSoftwareDevelopmentCo.
In my experience, waterfall project plans were never meant to be in stone, they were just a guide to give us an idea of what the project looked like. I've done a 3 year plan too. I'm sure some places implemented it strictly, probably government or heavily bureaucratic institutions.
I started writing out the whole story, but in a nutshell: my formal background is a dual EE/CompSci bachelors, followed by an Masters in CompSci that focused on distributed systems. When I was a kid, I learned to program very young: Basic around 8, C in DOS around 11, C on Linux around 13. I fiddled with electronics some, but didn't really get it. I took the EE part of my schooling specifically because I wanted to learn more about how computers worked "under the hood" so to speak.
From there, I ran a web consultancy for a while, and ended up with a client that had a more math-heavy project. And then another client showed up with a project where a microcontroller made sense, and then another... My business partner was moving across the country, and I was enjoying what I was working on quite a bit more than I was in the web/mobile space, so we decided to part ways. I still do the occasional web/mobile project, but they're generally hardware-related (e.g. the Bluetooth connectivity portion of an IoT-type system). Over the years I've accumulated probably $15-20k worth of equipment and software license, and the customers keep showing up!
We have similar backgrounds in a way. I started coding as a kid too, at age 9. First Basic, then Pascal. Picked up C in my teens. Also tinkered with electronics and was part of an online robotics mailing list that was a lot of fun. It was very hard for me to get parts, living in the middle of nowhere in rural Southern Brazil, but some folks in the mailing list were super cool and shipped me parts from the US. I live in the US now.
I'm a CS major but took electives in embedded systems in college, and those were some of the most enjoyable classes I took. I'm now working on recalling some of that. Ordered some PIC parts and I'm currently taking an edX course on ARM programming.
My only problem right now is, I have no idea how I'd get into that space having a whole career built on server-side software.
If you ever need any new hires... /u/cblum and I would like to have a word
I've always loved the carrel desk. It seems perfectly designed to encourage the state of flow in its occupant.
is it a form of abuse like trying to keep everyone under control? is it a form of psychological conditioning to remind you that you just a resource whose top priority is to be interrupted at any time so knowing that you don't really have any personal space sovereignty or privacy to your own thoughts or creativity but that you must answer and create only for the collective?
I don't feel I have a clear picture on what it's about any insights?
Open offices facilitate that feeling of persistent accessibility and production. No closed doors to slow anyone down, and no notion that you are there to do anything but work every minute of every day. So why on Earth would anyone need privacy?
This is full-on agile ethos. And, for the same reason, agile is also responsible for the reversal of telecommute policies at some companies.
When I call someone and in the background I can hear 20 other people talk, I immediately assume that the person I called is not considered important in his/her company. Because high-level work needs uninterrupted quiet time.
For agile, it's similar. When you stop having different roles, then you implicitly assume that your lead architect and your junior trainee can do the same work, albeit at different speeds. If your architect has useful experience, that's an insult. Or it means that your entire product is simplistic enough to be built purely by trainees.
So both open office and agile effectively reduce your programmers to expendable grunts.
Also (and somewhat contradictory to the above), I expect that, if your colleagues are _too_ easily available, you'll be running to them with a half baked question in your head, only to blurt it out before realising you didn't think it through, and wasting both their time and your own. But before you go knocking on someone's office door to ask a question, you really want to be sure that you know what you want to ask, and that you understand the problem well enough for the answer to make sense to you. Which leads to a better conversation, less time wasted, and better learning.
The crazy extension of this is "free desks" where basically every place is a workstation, and you don't have any space to call your own.
I have similar views on wfh, fwiw. Like 1-2 days a week is fine for me but full time remote is far too isolating IMO.
Fresh out of undergrad, open office layouts feel familiar to the long hours spent sitting at big tables in library basements, so I can see why some people like it initially. After a few years, you will be pining for four walls and a door to get anything done.
> The difference is, with your own space you can do deep work on your own terms. No longer is your train of thought constantly interrupted
What's wrong with headphones for deep work? Or appreciate not everyone has these, but where I work atm we have small 'quiet zone' booths where you can take your laptop if you really want to focus deeply.
As for being interrupted, again maybe it's just a company culture thing. Where I work people are generally pretty respectful if they see you with headphones on intensely focused on something, they'll probably just ping you a message on slack asking when's good to talk. But equally if people have headphones off, open body language- everyone feels happy to strike up conversation and there are no barriers in the way of collaboration.
So to my generation, this bouncing ideas thing is less of a requirement because we're used to doing our own work.
If you look at scientific papers from fifty years ago, most had just a few authors, now many of them list eight or ten.
The team approach seems to be taking over the world. However, I would point out that most truly great work, think Nobel prize, or truly awesome engineering work (K&R, UNIX) has till now mostly been achieved by individuals or by small teams, and that there was a lot of focused individual effort put into them.
I don't mean to sound condescending at all, because the young are going to win out by default, you guys are the future and we are the dinosaurs. You preferences and work habits will become the correct ones (whether they are better or not).
However, I would suggest that you like open plan environments because this preference has been trained into you since early grade school.
What I really hate is filling in form A, which directs you to form B, which you fill in to see whether form C is required. Form B was put in place by a legal team, who don't provide any point of contact, and who are not your friendly local legal team.
Because the process of filling out forms is so time-consuming, your engineering team uses Asana to track it. However, your PMs use an excel spreadsheet, the legal team uses JIRA, your copywriters use a google doc, and the teams that own forms B and C use separate internally created tools. You update your form-filling progress in 6 different places, some of which have bugs and others of which aren't actively monitored, so you also have to use email/slack/skype messages to follow up the right people. Some of the right people are actually the wrong people. Some of the right people reject your proposal because they didn't read it properly. A few of them reject your proposal for reasons that are actually valid, but which you could not possibly have known, because they're based on tribal knowledge which is not documented anywhere.
Filling in the forms and fixing the issues takes literally 3 months and at least 4 group meetings as well as several skype/zoom calls. One day you are finally allowed to write the code. It's 150 lines including tests, across two services, and you're done in two days. Everything that caused your proposal to be rejected would have been found in development. You quietly wonder whether you would have been happier as a bricklayer.
Anyway, I think my comments on CI/CD, Git, etc are being misconstrued. I'm not saying they don't have value. I'm saying they are frequently part of an ethos that leads to developer burnout.
For instance, your CI/CID process is one you must "appease", along with the rest of the bureaucracy. It may not feel as odious (and may even seem a relief, relatively speaking), but it contributes to your total load.
And, Git is fine. In fact, perhaps even perfect for the current culture (in philosophy, if not always in execution). Each developer has his/her own repo, you can work offline, you merge instead of locking check-outs, etc. But, that's the trick: it feels perfect because it allows you to work in the always-on philosophy of agile. Its popularity sprang up because this world of high burn-out, constant productivity demands it.
So, we can see the utility of these things and even appreciate them. But, the model they enable and expectations they create can still ultimately lead devs to burnout.
A lot of the comments in this thread are pretty funny to me. CI systems are awesome when they are working. It is a real pain in the ass not knowing when something is broken or not being able to find out when it broke.
Similarly, writing good tests is really helpful for me. I do this even on my own personal projects.
These things are so helpful to me that these comments are like reading about people who hate source control.
>writing good tests is really helpful for me
I'd wager it's partly generational. If you came up in the agile world, then you likely see the upside but not the down since there's no reference point for the latter. Because, of course it's cool that these CI build processes kick off at commit points (or whatever). And, of course, the near instantaneous feedback that something is broken is more efficient than awaiting a nightly build. OTOH, we were much more cautious about the code we checked in because the stakes were higher and you didn't want to be the heel who broke the build. "Move fast and break things" was not a thing. Instead, "be thoughtful about what you're claiming to be good code" was the ethos.
But, this is not an argument about efficiency or whether these things can be made to work. The argument is about the cost to the developer of all of these things in sum, and the philosophy they serve.
Likewise with TDD. I'm not arguing that tests don't help code quality and I've heard others say they like writing them. YMMV and all that. But, it's more load on the developer and I've definitely seen it overdone.
So, again, without the reference of a "saner" world then you don't likely have the context to fully appreciate these costs. I see them, though, and frequently hear them when people complain about burnout. It's not CI/CD or TDD or whatever that's the problem. It's that these things are frequently used less as tools and more as the instruments of a philosophy that plugs developers in alongside them as just another part of the never-ending pipeline.
Then I started working at a big company with a good engineering culture, I learned about writing tests and related tools, and had a much better experience. Now working without these things feels like driving without a seat belt, or maybe using a grinder without safety glasses (car accidents are too rare to be similar to bugs being introduced...).
I still have fun writing personal projects. It's just better with tests and CI. It sounds like you are pointing at issues with management styles that just happen to exist at the same time as useful tools like this, but I think they are almost if not completely orthogonal.
Not sure I'm getting my actual point across though so, rather than repeat myself, I'll just say the "continuous" part of CI/CD has implications on us as humans that are difficult to fulfill over the long-term. So, maybe really consider that word continuous in this context. We're just not made to be cogs in an automation pipeline that never ends, which is essentially where the philosophy (and its enabling tools) places us.
So, it can feel fine and you can see the merits of the tools, etc. But, none of that precludes the burnout that so many devs ultimately face over time.
A quick test framework that doesn't require too much boilerplate, a Github Actions CI that runs in a few seconds and help me, continuous deliver that has everything figured out for me?
I think those are a net positive.
When it makes my job a living hell? Nope.
A CI that takes 40 minutes to run? A CD that requires manual intervention and has "a line" of builds and you have to babysit your build? Testing that requires multiple lines of boilerplate?
Then I'd rather live without those things.
Now... don't get me started about JIRA and other tools, which are a tool for micromanagement.
As a graybeard, I've seen multiple generations of "how to do software" and the most recent are the least fun. A lot of this is driven by the agile approach. It's tailor-made for dev burnout: from the endless tight cycles that force people into an infinite loop of productivity with scant satisfaction that comes with "completion", to all of the tools and philosophies designed to juice that endless loop to be successful/workable. CI/CD, Git, TDD, etc. These all impose on the developer's creativity, independence, and enjoyment. They turn devs into cogs--assembly line workers who must not stop the line at any cost.
One example: back in the day there was a nightly build, not a continuous one. And, you checked out a file, worked on it, and checked it back in. If someone else needed it they had to wait. That obviously had its limitations and it seems laughable by today's standards. But, it was reflective of a human pace that considered devs as people vs. optimizable assets. That is, it was workable because the expectations on devs weren't insane. But, now we commit and merge. Think of how much less fun it is to spend your time resolving merge conflicts.
More to the point, the approach itself implies a chaotic pace wherein code that meets the standards of a certain box must be produced at all times. Devs must bear the cost of resolving any conflicts (literally) that arise from this chaotic pace.
Likewise, with CI/CD. And don't get me started on the monkey-work that is TDD. You might argue that it improves code quality. But, it's hard to make the case that it improves job satisfaction. If you move more work from the creative, problem-solving bucket into the busy-work bucket, the result will not be personal fulfillment.
Does agile increase productivity for companies? Sure. But, it comes at a high cost that's mostly paid by devs.