I’ve been a web developer for several years in various agencies and capacities. I worked in small and large teams, on small and large projects. But 4 months ago, I pulled the plug and left a career as a full time coder. Ever since, I’ve been a lot happier and my stress levels have decreased significantly.
I’ve seen the web development seen evolve over those past years. Some things changed for the worse:
Specialisation. When I started out, you could be an all round programmer working on a medium project by yourself or with a co-worker. But over time, technology has become increasingly complex. As a result, you had to specialise. I had to quit doing frontend development and specialised in backend work And then, I’ve noticed how coders tend to specialise in an even more narrow field/framework. Personally, I ended up dealing with anxiety about the longevity of specialised knowledge as technology obsoletes at very fast pace. Internalising an entire new framework (API’s, ways of working, etc.) takes a lot of effort, is it worth my while if that knowledge becomes worthless in a matter of 3 to 5 years and I have to start over? If you value your family or social life, trying to stay ahead of the wave becomes an unattainable goal.
Standardisation. Because of the increase in complexity, most agencies have adapted the development process. Either they introduced more bureaucracy or they compartmentalised your job to several well defined tasks in order to increase efficiency/profitability. The widespread skewed adoption of practices like “Scrum” or “Agile” accelerated this process. A developer is only responsible for a set of “tasks” or “user stories” that need to be delivered on time. Theory dictates that Agile creates a positive feedback loop between management and developers. In practice, I noticed how “Agile” often becomes a crutch for obnoxious or petty micromanagement by the top level and even among developers themselves. Even worse, “Agile” can be a guise to deny any “slack” time such as self-learning, exploring alternative ways of coding, etc.
In the end, I felt no joy as my job had turned into being a part of an assembly line. It’s hard to take pride or ownership of a piece of backend code that you have to hand over to someone else to finish, knowing that it’s going to get altered further down the line. It’s even harder when you have to deal with the all the micromanagement at daily standups, sprint planning and retro. In the end, coding had turned from a fun hobby/learning experience into a dreary job.
Then there’s the way how the industry presents itself on social media. It’s like everyone is constantly going to cool conferences, doing cool projects or organising cool internal workshops. Everybody is labeled a “creative” or an “innovator” or an “entrepreneur”. Everybody seems to have a side business or a successful open source project. Don’t drink the kool aid! Most of us are just regular guys/gals who want to go home at 6PM and do mundane things like going for groceries, cleaning, taking care of the kids and what not.
So, I pulled the plug. Today, I’m still in IT but I’m a consultant with a non-profit. Coding is maybe 5% of my day job. I’m mostly talking to people, thinking about practical solutions on a more abstract level,… Like every job, I’m having good/bad days. But at least I’m not being constantly pressured into performing. More importantly: I do have a large say in how my day will look, and what the output of my work will be. I take pride again in what I do, with my regained responsibilities.
I’m still writing code and learning new things. But I’m doing it from the comfort of my home an at my own pace.
I’ve worked off and on in technology for 15 years, and I think this is definitely true.
Things were way simpler 15 years ago, and because of that, programmers had a more holistic relationship to projects. Everyone was a “full stack” developer because the stack wasn’t that complicated!
Along came AJAX, pages with lots of client-side functionality, highly scalable database infrastructures (including “No SQL” ones), more complicated deployment schemes, etc. Everyone is a cog now, and this makes it easier for management to replace people.
With respect to agile, I had a very rough time with being micromanaged also. (It’s less a problem where I work now, though there are other serious issues.) There was this blog piece written recently, which is a bit heavy-handed in tone, but it’s really right on about why agile is so damaging.
Thanks for sharing, could you tell us more about your new position, I have the following questions.
What kind of non-profit are working you working for, do you share their goals and values?
Are you making less or more than you used to make as a developer?
Could you share what a typical day would be at your position?
Once again, thanks for sharing. Like you, I also believe that specialization and the new development methodologies are a contributing factor to depression and anxiety among developers; more and more I see companies treating developers as specialized “factory” workers.
Thank you for sharing that article. The ensuing discussion in the comments is interesting as well.
I think this is an important quote:
Agile has no exit strategy. There’s no “We won’t have to do this once we achieve ” clause. It’s designed to be there forever: the “user stories” and business-driven engineering and endless status meetings will never go away. Architecture and R&D and product development aren’t part of the programmer’s job, because those things don’t fit into atomized “user stories” or two-week sprints. So, the sorts of projects that programmers want to take on, once they master the basics of the field, are often ignored, because it’s either impossible to atomize them or it’s far more difficult to do so than just to do the work.
In other words: it’s easy to end up in a zero-sum game. There is little gain for developers to work harder other then:
Considering the process as a game and burning more points achieves you a higher score.
Hoping that the next story will somehow be more challenging/fun/… to do.
Hoping that financial targets will be met through your speedy work with - hopefully - some kind of bonus compensation.
Neither of these bullet points are incentives why one would choose to become a professional developer in the first place.
Moreover, an aspect of the “holistic relationship” you mention is ownership. If you don’t feel like you “own” the project, there can only be so much sense of - long lasting - pride about your work. I’ve always considered development and design as a craft. It takes craftmanship to build a well designed website. Standardisation and specialisation are the exact opposites of craftmanship. They make it easy for management to reduce work to sets of KPI’s that can be used to base all strategic and operational decisions from. As “sense of challenge”, “sense of achievement” or “sense of ownership” can’t be expressed as a business value, they are most often just ignored.
Put it like this: The first time building a functional product carousel on a webshop is an awesome achievement. Having to do it the 500th time is not. Especially if you have only little say in the value that the carrousel adds to the overall project.
In the end, there is little incentive to identify with your work or the company you work for. I think it’s one of the reasons why there is such a high turn over in company workforce.
The comments do make an important point. Agile and Scrum are models, and often they are just implemented directly “as a silver bullet” in a company with little forethought. Thus that make them bad practices? Not necessarily. They are the sum of much older principles. Companies still have to organise themselves somehow. The challenge is to find the fine balance between a people-centric and a business-centric perspective. The ugly truth is that this is - and always will be - a constant exercise as your company, your clients and your team evolve.
A good - albeit quick - read on the subject is “The year without pants” by Scott Berkun: