Being a Software Developer Sucks!

My Background

From a very young age I discovered my love of tinkering with electronics and a fascination with computers grew.  By the time I was seven I had my first computer, a Commodore 64, and started to code.  The first programme I ever wrote simply asked for my name and then responded, “Hi Guy, how are you today?”.  Despite the simplistic three lines of code this blew my mind – I could see a potential for what I could achieve with this tiny beige box sat on my desk.  From that day on I coded.

 

Growing up there were very few things that I was sure of.  The one thing I knew for certain was that computers would be my life and that of all the areas I loved, software development was at my core and would be my career.  Before my teenage years, I’d written code on half a dozen platforms in different languages and once I had the internet my interest grew exponentially.  For years, I had tinkered at home and school with networking and distributed software development on just a handful of machines.  Once the internet had arrived in my life the scale was unprecedented.

 

By the age of 15 I started as a freelance developer.  It was the height of the late 90s internet boom and money grew on trees.  I could earn £50 per hour for the work and an additional 50% of royalties for products resold.  When it all burst one client I worked for vanished owing me £60,000 but I didn’t really mind as I still wasn’t even 18.  Over the following years, I remained working as a freelance developer along with undertaking a computer science degree and then running my own software company for a few years.

 

In 2010 I decided to look for stability in an attempt to “grow up” and went to get a “proper job”.  During my undergraduate years, I’d worked for Hewlett-Packard for a year and found it thoroughly uninteresting and without challenge.  I was hoping it would be different this time and got offered an excellent opportunity at Symantec working in their “.Cloud” business unit developing backend APIs.  I only kept that job for 18 months and one day (which turned out to be my longest stint as a permanent employee) and during that time made leaps and bounds.  I received promotions, pay rises, was given internal awards, got to fly over to California to attend an internal technical conference after my work on B2B mobile apps within Symantec and had the SVP willing to work with me directly on a track for CTO.  The opportunities were great and the people were great.  But I was bored and an inflated sense of self-worth told me to take a pay rise of 100% at another company where I then went to lead their mobile apps development team.

 

Things went well there. I was pivotal in all the sales we bought in, I got to work on some really interesting projects, trips around Europe and weekly flights around the UK were a nice luxury and at the age of 27 I was already earning double the average developer salary.  I got to start working as a technical and solution architect as well as presenting to CXO levels.  The problem was I got bored and started to question software development as a career.

 

An interesting job offer presented itself, it was working as senior management in a telco responsible for managing the teams that created everything public-facing (APIs, mobile apps, web site, etc).  This time I lasted 11 weeks before the boredom broke me despite the fact I was now in to six-figure-salary-range for mostly drinking tea.

 

At this point I decided to abandon being a permanent employee and go to work as a contractor.  The idea was that I could leave places really quickly and work on small and enjoyable contracts without all the crap that is associated with being an employee.  I got a contract with a large mining company and was “technical lead” for one of their luxury brands within the diamond sector.  This was without a doubt my most interesting role – hardware and software integration, a lot of domain knowledge to learn, some really great people I got to work with and a (mostly) free reign to improve their systems and processes.  I worked as a developer, technical architect, solution architect, enterprise architect, DBA, scrum master, technical team leader, pretty much everything in some capacity.  By two years I was bored but I promised to remain for a third year to finish a large project.  Without a doubt the longest I stayed and the money certainly landed me into the “ridiculous” category – often bringing home 5 to 10x the average post-tax developer salary.

 

During that contract, I decided I was done, applied to go back to university and took a temporary contract near where my course would be for five months.  It was meant to be a six-month contract but this time I couldn’t even manage six months and left after five.  After that the rest is history and I went bankrupt and am a tie-dyed student once more.

 

What’s Wrong with Software Development as a Career?

So, that all sounds awesome.  The real question here is what’s wrong with being a professional software developer?  I can only answer from my own perspective as everyone is different.

 

To start with I suppose I should list all the reasons to consider becoming a software developer.  Let’s assume you have some fairly decent technical skills – if that’s the case then it can be a great opportunity.  The money is good.  If you’re willing to “play the game” in business and go beyond just sitting and doing work you’re asked to then the money can be six-figures good and chances come along to get involved with start-ups and earn equity.  There is a scope for variety in your line-of work (technology stacks, scale of system and moving from dev into architecture).  This is even more true these days with hybrid roles where you’ll get to do everything including user interface, APIs and mobile apps.  What’s more with the right company you can chose a job that suits your needs – do you want to fly around the world?  There’s a role for that.  Do you want to hide anonymously in a large company and mainly drink tea?  That’s definitely achievable.  What about a small start-up five minutes from your house where you can get involved in everything and even work in your pants?  No problem.  Just from the top of my head over the last few years alone work took me numerous times across three continents with months spent on expense accounts eating and drinking.

 

Most importantly you’re unlikely to be out of work any time soon.  Over the last twenty years I’ve seen the technology sector grow.  First there were a few tech companies providing services that others used but more and more companies started writing their own software in-house where bespoke needs were required, then more tech companies tried to create catch-all software to fill that need but then companies needed even more customisation.  I would hazard a guess that the world is at such a place that every single company – whether one-man bands or multi-nationals could do with an IT department and within that there’s definitely a role for a developer.  Not all companies have the budget for the world’s biggest IT department but stop and think for a minute just how many jobs that creates.  What about the robots that will be taking all our jobs?  Good news – at least until self-replicating AI – they will need a human overlord to develop and maintain the system.  I have recruited many people and my best friend is a CTO serving a totally different geographical location.  For both of us we have found recruiting difficult – there are just not enough candidates.  If you’re good you can work pretty much wherever you like.  If you’re terrible, you’ll still get a job within a few weeks of searching.  If my experience is anything to go by once you’ve got a job you’re unlikely to be asked to leave as even if you only contribute 1% of the best employee in the team losing that 1% of knowledge costs more than keeping you there drinking tea.

 

So, you can pretty much have a job wherever and whenever you want.  The money is good.  There is no physical labour.  There’s a wide range of roles.  Often the cultures in companies can be “fun” and “relaxed”.  So, what’s wrong with it?

 

This all depends on who you are.  Do you care about your job?  Is it your passion as well as just what you do between 9am and 5pm?  If it’s just a job and you’re considering being a developer – do it – rarely have I seen such a person unhappy.  I believe the problem comes when writing code is something you’re really passionate about.  If you spend your spare time coding, if you care about the underlying implementation details of not just a framework but a language and compiler to get the best from your solutions or if you really see the “big picture” of every part integrating and working in to the future then it’s a different thing.  Because commercial IT does not care about that.

 

There is one motivation in businesses – creating a product.  A start-up needs to create a product as soon as possible – otherwise nobody eats or get paid.  There is then a slight sweet spot in growing said product to a massive scale quickly before they move in to “established” territory.  An established company will always have a pipeline of development work – a never ending flurry of continuous and often monotonous requirements that are needed now.  The one thing all stages of company life share is the requirement to deliver.

 

Delivery is almost always directly at odds with creating a perfect or beautiful piece of software.  If you’ve ever run your own company, you will have had to make judgement calls that sacrifice either the business or the technology.  When you’re working for someone else a decision is almost always made that the technology will be sacrificed “today” to fix it “in the next release”.

 

So, the backdrop of my experience is overwhelmingly that working as a commercial software developer is wildly different than working on fun projects you enjoy yourself.  Why is that?

 

The 80/20 rule.  You can apply it to anything.  Actually 80% of the time you can apply it and 20% of the time you can’t.  See what I did there?  Generally, in a developer’s context the idea is that 80% of the work takes 20% of the time and the remaining 20% of the work takes 80% of the time.  The problem is that as a developer the 80% of the remaining time for 20% of the work feels like a real grind.  The fun bit is done, the product is functional but there’s that really weird scenario that will be used by nobody with a thousand validation rules.  Urgh.  This 80% of the time is mostly just a continual stream of nothing much fun happening unless you only ever work as a contractor during the initial couple of months on a project.  So much validation, so little enjoyment.

 

Meetings.  Sometimes it’s necessary to have a meeting about the meeting you’re going to have.  But what if there’s a few people in the pre-meeting meeting?  In that case, you may want just a brief meeting beforehand to make sure that you’re all “singing from the same hymn sheet”.  There’s nothing worse than getting your wires crossed and having to “take it offline”.  Yes, meetings are the death of productive teams.  Not every team has meetings.  There are certainly roles you can do that just let you develop but as soon as you become more senior you’re not getting out of them.  You may be invaluable to team productivity in a hands-on role but by that point the knowledge you have accrued in your own head (nobody reads documentation, your brain is the documentation) means that you will be attending a lot of meetings.  If you only work in a small agile culture and money isn’t a motivator and you’re happy lower down the food chain, you may escape this pain but otherwise you’re going to learn to hate that Outlook popup advising you that you’re going to lose two hours of your life that you’ll never see again.  A single 30-minute meeting consists of preparation, getting there on time, talking to people afterwards and then getting “back in” to whatever you were doing.  Expect half a day gone in lost productivity and with a multi-national that’s going to happen a lot more.

 

Jack of all trades, master of none.  Or as one company I worked for even liked to proclaim “a mile wide, inch deep view”.  You’re aware of Docker as a developer but you’ve never really had to consider how the servers are setup.  Virtual machines seem to give you an endless supply of servers but what happens when your database is constrained by I/O throughput?  You need to call that pesky web service but the firewall seems to be blocking you – or is it down?  Your federated authentication was working great until there was one tiny, but super-important, feature that doesn’t work with the library you’re using and now you have to home-brew your own SAML2 stack – what are you going to do?  As someone passionate about technology I like to consider myself to have a mile-wide three-quarter mile deep knowledge.  I can take you down the TCP/IP stack to what runs over the wires (or within software defined networks).  I have a home lab to play with all aspects of infrastructure and have spent my life getting to the point that I can happily work in any role from architecture to development to infrastructure.  I consider this a necessity to be a good developer – without consideration of how your solution will actually work when 10,000 users are calling it simultaneously all on flaky 2G data connections you haven’t got a solution at all.  I have found the overwhelming majority of developers that I’ve interviewed or worked with (at least 95%) do not have this depth of knowledge.  I’m fine with that knowledge lacking at a junior level but these days it tends to permeate right to the top of teams meaning infrastructure and dev work in completely different silos.  The concept of “dev ops” has not fixed this and is just a fancy buzz-word as far as I’m concerned.  This only covers the lack of mile-wide knowledge but what about if it was really deep?  How many .Net developers can tell me what happens in detail with garbage collection?  How does the underlying implementation of a hashtable impact your particular usage?  What even is endian-ness? Not massive questions but I am amazed how many people cannot answer a single one of those.  The real issue is a skills issue which means most projects I’ve worked on have felt incredibly frustrating at points.  Yes, there are good developers but there are far more developers lacking knowledge both of development and across the board – and you have to work with all of them.

 

It’s all about that stack, about that stack.  You want functionality?  You want it to work?  There are some NFRs mandating performance?  Forget all of that because CrazyFun.JS 5 has just been released and it can run on a Xylon.Awesome 7 backend with a completely new, and relatively untested in this particular scenario, Quantum data store.  What’s better is that we can test all of this without any effort what so ever with a single button and it will give us lots of metrics and green lights.  It doesn’t get better than this.  Until next week when CrazyFun.JS 10 is out and that’s not even used because Schrödinger.JS seems to solve a totally new paradigm.  I have sat with so many teams who have spent days and weeks excited over what stack they will use – the current favourite being Angular.JS and Node.JS with along with a completely unnecessary document-oriented database.  We’ve spent weeks discussing and prototyping but at no point have any of these questions been asked: “What is the supportability in 5 years’ time?”, “Have we run a test against specific NFRs that we have no evidence this works out?”, “How will we scale this with intended business growth over 5 years?”, “How easy is it to hire people to work on this system on an on-going basis?”, “Does the simplicity provided by X framework actually mask some of the complexities so much that we limit our customisations?”, “How will this work when we inevitably start to upgrade parts of the stack independently in the future?”.  There’s so much excitement about choosing frameworks that do most of the work for you and are “cool” and “fun” that no business consideration is made and no practical implications beyond the dev team are really made.  What’s worse, for me, is that this feeds in to the previous point – developers do not know the detail of how a system works.  How a call is made from client-side JavaScript to a backend JSON-based API is largely abstracted away meaning when something goes wrong diagnostic knowledge is missing.  Over the years that I’ve seen frameworks grow I’ve seen average developer knowledge decrease.  What impetus is there to know how something works if you can just pick a box off the shelf, put it against another box and it all works?  That’s great until the box breaks, or you need to change the box or there is nobody left to build any more boxes.

 

Spaghettification.  A word that you cannot begin to appreciate until you stumble upon a DLL, that some of the most leading names in agile practices and software architecture have worked on, simply called “<BusinessName>.dll” containing not just business logic, data tier or front-end Windows application but ad-hoc hardware integration and core web functionality all bundled together.  This means your web server needs a camera driver, MATLAB, 32-bit Word and more just to run a simple ASP.Net site.  But it’s OK, it’s tested.  That’s right there are 20,000 tests, and a further 5,000 that have been turned off as they no longer “go green”, so why do things break whenever it’s released?  There is so much green to instil confidence during the four hour build cycle.  One day you decide to try and fix something and just need to put a break point in and debug it.  But in the 20,000 classes in the same assembly where should it go?  It’s a client component so definitely not the Server folder, right?  Nope.  Oh, everything is an interface yet there’s only one instance of it?  This may make it harder to determine the route of a call stack.  Urgh, facepalm.  This is but one of many first-week-in-the-job experiences I had.  The people that wrote this system were good and are very well known and I too respect them – yet this still happens.  This is what happens in the real world when people get new jobs (every 2 years on average in software development), new frameworks come along (see all the issues above) and there is still a never-ending impetus to “deliver”.  It happens almost everywhere.  You’re not going to avoid it by working in software development unless you’re always on greenfield projects.  That swanky tech company in California you’re thinking of right now whose app you use every day?  Yup it happens there too, trust me.

 

The business.  All hail “the business”.  Those words almost have mythical significance.  There are so many problems here because a company wants things now and it changes its mind often.  What kind of things happen here?  Things don’t get released – far more often than you’d believe.  Quite often timescales are determined by when it’s wanted rather than how long it is realistically possible to deliver it in.  Specifications and requirements are often incomplete or don’t match reality.  Everything must be green – regardless of what the metric means and the impact fudging it has.  There’s just a lot of bullshit here.  People are resources.  Finishing something is delivering it.  Talking to someone outside of a meeting is taking it offline.  You regularly stratergise.  Everything delivered is bug-free.  It’s a lot of nonsense.  Sure, this isn’t the case for every company and those following true agile principles are a lot better at this – but this does happen at most places.

 

It’s all a load of CRUD.  The worst thing though?  It’s all the same.  Odds are your project involves a distributed API, some kind of front end and a lot of CRUD operations in the backend.  Yes – it may be at scale, it may even be working on a computer game – but once you’re in the swing of it most of your work does tend to be lather-rinse-repeat.

 

In Summary

Whilst writing this blog it’s given me time to think a lot about my own relationship with development.  There is a lot wrong with the commercial side of being a software developer depending on your perspectives but I can see, having written this, that I am definitely jaded.  There are many cases where businesses have been terrible places to work as a developer but there have also been many times I haven’t engaged with new technologies as I’ve seen it to ultimately be a wrong way to do something rather than what makes sense within that businesses context.  I may even start to admit interpreted languages have a place in the “real world” at some point (that’s an entirely different conversation for another day) and that node.JS is valid for backends.  Who knows what the future holds?

 

The reality though is that working as a software developer in the overwhelming majority of roles is not the job I want.  It is an excellent job with good hours, pay and culture in many regards.  The higher you go up the chain the more pressure you receive and more removed from doing the work but that’s true in any job and sadly those who are best tend to get promoted the quickest so that they can no longer do what they’re good at.

 

I wish that software development looked more today like it did in the 1980s and 1990s where it was less of a mass-produced factory and more of a skilled craft put together by people with a deep top-to-bottom understanding.  The reality is that won’t work though and as we go forward I can see how serverless architectures (AWS Lambda, Azure Functions, etc.) remove the need for even more knowledge.

 

It’s an ever-changing industry and that’s a good thing.  It all really depends what you want for a job and what your tolerance levels are.  The things that infuriated me the most – lack of resourcing, inappropriate timescales, poor project management and lack of foresight – are unfortunately always going to be part of the process in all but a minority of roles.  Business delivery considers everything with a different set of eyes to the IT department and there is always a trade-off.  I just didn’t enjoy working in it.

 

That leaves me with almost 20 years of commercial software development skills and back at university whilst I consider what to do next.  At the moment, I have no idea what that is but the one thing I do know is that I’m enjoying coding again.  I’m enjoying working on projects.  I’m enjoying learning new frameworks for no purpose other than because they exist.  I’m enjoying tinkering with hardware and infrastructure.  I’m enjoying integrating with hardware and making robots move.  I’m enjoying not having any hard deadlines.  I’m enjoying not having to consider the 80/20 rule.  I’m enjoying forgetting user validation.  I’m enjoying solve problems just for the sake of solving problems and never having to finish them.  That, I suppose, is the purpose of life.  I used to spend 12 hours out the house every day – that’s 2,760 waking hours per year out of approximately or roughly 50% of my waking life.  Whilst the job may have its benefits they did not justify spending almost half my adult life doing something I didn’t love any more.

 

Software development is an excellent career for many people but much like running a music magazine was a bad idea for me when I truly loved music (I became very jaded there too) being a software developer in the traditional sense didn’t work for me either.  I’ll stick to random projects and working in my underpants at home for now I think.