The many ways I’ve fucked up and what I’ve learned in my first 10 years as a Software Developer

Colin Wren

Apr 12, 2020·24 min read

I graduated with a BA (Hons) in Digital Art in 2009 and managed to land my first full-time job as a developer in April 2010.

In the last 10 years I’ve held six roles at three companies, run my own company, built a number of apps on the side (for free and for money) and made a hilarious amount of mistakes.

I’m a strong believer in the whole learning-not-to-touch-the-stove-when-it’s-on approach to skill progression and I find often the best people are those with some magnificent war stories which is why when I read of stories of CTOs firing and threatening to sue Junior Developers for making avoidable mistakes it saddens me that some people aren’t given that room to grow.

In order to journal my career progression I’m going to focus on the positions I’ve had as an employee and break this post into the different roles I’ve held and detail the challenges I faced and the fuck ups & the lessons learned.

TL;DR;

• I fucked up in my first job by thinking I owed them more than I did and put the interests of the company before my own career progression but I learned about working in a hierarchical office environment
• I fucked up in my second job by looking for mentorship where there was none and by breaking the age-old adage of mixing friends with business but learned about building a quality product and managing a team
• I fucked up in my current job by doubting the value of existing work when handing over to a new team but learned about working in a large-scale team, that being a jack-of-all-trades is a great thing to be and I finally learned the power of a good BA
• I want to spend the next 10 years fucking up and learning more

New Media Officer — St George’s Healthcare NHS Trust (2010–2013)

This was my first office job having spent my teens and university years working in a kitchen at a private school and a Wetherspoons pub once I was old enough.

The team were all about six or more years older than me so there were a few difficulties when it came to small talk as they were all settling down and buying houses and I was still living payday to payday.

It was a bit of a culture shock for me, the NHS (UK’s National Health Service) is a very middle-class environment and I was from a working-class background with a pretty hefty chip on my shoulder (something I’ve spent the last five years removing).

My role as New Media Officer was to take care of the trust’s website which at the time was a collection of Classic ASP pages with the most dynamic aspect of the site being the navigation.

This role was great for growth, as during the period I was able to take part in a number of digitisation projects that showed the benefits of web technologies in the NHS (a slow moving environment at the time) and I was able to ride the initial wave of both social media use and app development for the public sector.

The social media side of things really took off and I ended up helping to run a Twitter chat called #nhssm that discussed how the NHS at all levels could use social media to help patients.

This led to me writing a few opinion pieces for trade magazines such as The Nursing Times as well as national newspapers such as The Guardian and Financial Times, all great ways to increase my network.

While I enjoyed the social media aspect of the role, my real passion was in the development of websites and mobile apps that helped patients and hospital staff.

I did a number of projects that made it easier for patients to find their way around the St George’s site (it’s the biggest in London) including having Google add indoor-mapping to the hospital on Google Maps (I got in the Evening Standard for that one!).

Ultimately however while I was given a lot of freedom to build these tools I was meeting a lot of people who were earning more in the private sector and that in conjunction with some offers to do paid development work on the side left me a bit bitter of my career progression possibilities.

This all came to a head when I was told to market one of the apps I had built in my spare time for the trust to other NHS trusts for £30,000, I would have to make three sales of this app in order to move from Band 4 (£18k) to Band 6 (£30k).

I didn’t make those sales as the first interested trust quite-rightly figured out they could just offer me a job instead. I ultimately declined that job because at the same time a couple of guys I had met at a bunch of events (namely NHS Hack Day) offered me £32k to join their healthcare tech start up as a Junior Front-end Developer.

Challenges

• Old technology — When I was learning web design at university I was told IE6 was dead, St George’s didn’t get rid of until 2013
• Professionalism — The NHS clerical office environment is very hierarchical and stuffy, something I didn’t really honour and I would often get reprimanded for talking to my ‘superiors’ as if they were my equals
• Fighting for respect — Similar to the professionalism challenge I had to fight constantly with clinical staff to gain their respect as a subject matter expert when it came to development, UX and content as every six months or so I’d have to bring an externally developed department website into the corporate site and this would mean the staff member who commissioned it had wasted money
• Lack of mentoring — I was the only developer in a team of six communications professionals and as such I had nobody to mentor me on development practices, something I’d have really liked having not come from a Computer Science background

Fuck ups & lessons learned

Putting a conceptual art project on my CV
This one happened before I even got the job!

In a bid to flesh out my technical skills I added a conceptual art project I did at university that tackled a taboo subject matter as I had used Python to build it, the project was part of a module called ‘Design for Simulation’ where the brief was to create a piece of digital art where the viewer would experience something others experience.

A lot of people in my class took this literally and recorded their trips on the bus to and from university, I was egged on by my lecturer to simulate some of the darker sides of the human experience so I built a chatbot that simulated talking to a Paedophile on MSN Messenger.

The bot was a very basic bot that had two dictionaries with certain keywords in the user’s responses switching the bot from using the ‘child’ dictionary to the ‘adult’ one, and the bot would proactively talk to people on the friends list of the account it connected to MSN Messenger with (in response to my lecturer’s comment of “you don’t track down online predators, they find you”).

Talking to my manager after I got the job he mentioned that my CV almost got rejected because of the inclusion of that project but the person who I was going to be replacing had vouched for the technical achievement of the project making me a viable candidate.

Not including a WHERE clause in my SQL statement
During my time at St George’s I built a consultant directory which allowed consultant information to be easily dropped into the website.

The directory was backed by a MSSQL database (that I had to fight IT to get commissioned, using another departments budget in exchange for building them something) which we only had one instance of and I would update the data in the database manually instead of using some form of CMS.

One day I had a really simple update to remove someone from the directory and so I went and wrote the SQL without really thinking only to realise a little too late that I hadn’t included a WHERE clause and as you can imagine all the rows disappeared from the table.

Luckily I had normalised the data to some degree so the impact wasn’t as bad as it could have been but it did result in me having to spend two hours rebuilding the data.

Thinking I was indebted to my employer
About a year into working at St George’s I interviewed at HealthUnlocked for a Junior Front-end Developer role and was offered the job but I ultimately didn’t take it even though I would have been paid twice what I was on at the time.

I felt that I owed St George’s something for giving me the opportunity (that pesky working-class mindset), what I came to realise about a year later after staying on at St George’s was they didn’t feel the same way about me.

When I was asked to sell work that I did voluntarily in my spare time to generate three times my to-be yearly salary I learned the very important lesson that while it’s nice you get given opportunities these opportunities aren’t gifts, they are fulfilling a business need.

Took a second job without being smart about it
Off the back of the #nhssm work I was doing I was given an opportunity by a friend to build a mobile app for money, enough money in fact to pay off all the loans I had been taking out to support myself after I moved out of my Dad’s in 2011.

I took him up on his offer and spent the next two months doing my 9–5 at St George’s, coming home, eating then sleeping until 8pm and working 8pm-4am pretty much every day.

The experience taught me a lot about productivity (all those articles about early risers applies to night-owls too, just in reverse) and at the end of it all I was able to walk into Lloyds TSB and pay off the remaining balance of my £4,000 loan in one go and that’s a memory I’ll always cherish.

However what I hadn’t done was account for the tax rate that would be applied to that extra income as I had never been taught how taxes worked, I had never heard of a capital gains allowance and didn’t realise that second-job incomes get taxed fully at 20%.

I soon learned this when the tax man told me in April the following year that I owed £3,000 in tax that I didn’t have. Luckily I was able to pay this back over the next year via PAYE but it meant my already barely-enough monthly salary would be £280 short for a year.

It’s safe to say the next time I build an app for money I make damn sure I set up a company to do the work.

Junior Front-end Developer— Healthcare Startup (2013–2014)

As previously mentioned I had met the management team (representatives of DevOps, Product Ownership and Dev Leads) at a bunch of healthcare related events while working in the NHS and we got on because we all had the same attitude about how open-source software could revolutionise the way the NHS built and procured it’s software.

I had joined the company as I wanted to flesh out what I saw as a skill gap in my experience. At St George’s I was empowered to build some really awesome stuff but I was never told what was best practise, instead I learned what worked and didn’t work by causing all kinds of issues and I didn’t want to do that anymore.

The company wanted to grow to build an open-source electronic observation product, having maintained various solutions for the NHS, and them never having their own, but the Senior Developer they had was more of a back-end developer so they needed someone with more front-end experience to make the web app they were building run well and look nice and so they took me on to do this.

I worked closely with them on building a responsive UI for the Play! for Scala based web app and dabbled in some test automation using Selenium, but unfortunately about a year in the business pivoted to bring the front-end closer to the Odoo based stack that held the patient data.

It was during this transition to Odoo that I got to learn a lot of what it meant to be a Senior Developer as the company hired someone into a Senior Developer role who was senior in their experience of Odoo and not their ability to help people grow.

After losing the opportunity to continue working closely with the original Senior Developer I think the mentorship I was hoping for evaporated so I was back to building what I thought was right only to get scalded later on when things blew up.

Fortunately for me, this lack of guidance eventually led to an incident happening that gave me the kick up the arse to take this mentorship need into my own hands and hit the books to learn from mistakes I made.

During my time I got promoted to running the development team which I’ll cover later as it had it’s own set of challenges and screw ups but the promotion was out of necessity we’d lost a Dev Lead and someone had to lead the team — that someone being me.

Challenges

• Inconsistent Mentorship — Of the three senior development staff only one of them actually tried to teach the junior developers best practises and when he left there was no more mentoring, just assumptions of experience that we didn’t have
• Functional Programming — During the early days I was working a lot with Scala and having come from a mainly Procedural background I struggled to understand how to work with it but I had a great mentor in a Senior Developer to help me in these times
• Distributed Team — This was my first experience working in a distributed team and a team that had people working part-time, this meant that people weren’t always available to help with issues and that took some getting used to

Fuck ups & lessons learned

Backing the wrong architectural horse

About eight months into working at the company the team had made the decision to use Odoo (then called OpenERP) to store the patient’s observation information as they were already using Odoo for workforce reporting in the product.

I was asked my opinion on which I had favoured, a well architected but complex separated front-end that had performance issues due to the Odoo API calls taking time to complete or bringing the front-end into Odoo which could bring performance gains.

I ultimately backed Odoo. It was easier for me to work with as it was in Python (a language I already knew) and the other junior developer was working on that so it would allow for redundancy in the team.

I feel this was a grave mistake and it would be about six months later that we were seeing the same issues with performance we had seen before and the Odoo codebase became completely unmanageable.

At the time I wasn’t really aware of separation of concerns and had no experience of horizontally-scaled architecture so I just looked at it from a purely developer experience and ultimately I think this decision pretty much sank the business.

Learned about testing the hard way by breaking the BCP reports
As the designated front-end developer I was asked to help build the HTML for the Business Continuity Process (BCP) reports we offered the customer as a means of ‘falling back to paper’ if the our electronic solution failed for whatever reason.

One day the HTML stopped being generated correctly due to what turned out to be a controller clash but the symptoms were blank PDFs being generated so it was assigned to me to fix.

During my investigation to see why this was happening I asked the new Senior Developer for assistance.

He helped to debug the report being printed by adding the line “This works” to return at the start of the controller. What I didn’t realise was that this was committed and as the company at the time was using trunk based development this went to production.

It wasn’t until about three months later when one of the clients phoned up and complained that the BCP drive was full of PDFs that said “This works” that we realised the issue and I got reprimanded by a Dev Lead as I was asked why I hadn’t written any tests to cover the functionality and the new Senior Developer who I had expected to support me simply shifted any wrong doing he was accused of onto me.

This really pissed me off as neither myself or the other Junior Developer were taught anything about testing, or the expectation that in trunk based development you’re expected to have written them, yet I was being told that I was on my final warning for what I saw as something caused by another party, as ultimately I committed no changes to fix the issue.

Regardless, I piped that rage into learning as I wasn’t going to let myself get fired over someone else’s mistake so I read up on agile development practices and soon became the designated quality person in the company, which then led to a lot of issues within the management team as this exposed some serious issues with the codebase.

Ultimately this was the turning point in my career, it made me realise that software development isn’t just about hacking together code, testing the happy path and calling it production ready, it’s about crafting a solution in a manner that will last years due to its ease to maintain and adapt.

Software Development Manager — Healthcare Startup (2014–2016)

My career progression at the company was highly un-coordinated being a Junior Front-end Developer until someone senior stepped down, then becoming a Senior Developer alongside another Junior Developer I worked with because we had been there a year and we had four new Junior Developers joining.

Six months after that I was made Software Development Manager after the company grew a bit more and they starting to retroactively apply the Skills Framework for the Information Age to people working in the company.

Up until recently I would have put this role as my favourite position I’ve held as I not only grew a lot during this period but I had an amazing team and a good level of autonomy, the only thing that stops it from taking the top spot is the elements out of my control that led to the company folding.

During my time running the team I hired a couple more developers, introduced a DevOps mentality into our development practices, looked to curtail the quality issues in the codebase and challenged the decision makers a lot on their assumptions.

The latter was my favourite part of the job as the DevOps and Product Ownership had an interesting dynamic:

• DevOps was originally about hacking a bunch of services together and sell ing that as a production ready solution, this was great for sales but caused a lot of instability with the changes being made
• Product ownership would constantly solutionise instead of listening to the end-user referring to the nurses who used the product in detrimental terms

In order to combat the instability brought by DevOps I got everyone in the company to read The Phoenix Project while I read a number of books about Continuous Delivery and building quality gates into the software development life cycle.

This meant the developers were empowered to see their code through to production and I worked with DevOps to take the collection of shell scripts and turn them into idempotent Ansible playbooks.

The side effects the Product Ownership weren’t seen until much later on and I really don’t think there would have been enough time to turn around the damage caused there but I still gave it a try, attempting to bring validated learning into the way we built the product and using user story mapping and personas to get him to understand the value we were trying to deliver and who we’re actually targeting.

All of this came to an end when in December 2015 I was in a meeting where it was announced we had about three months of money left and we needed to get new customers and actually retain them in order to continue (the performance issues in the product meant many customers didn’t opt to keep using it past the initial trial period).

Because the NHS works very slowly the sales never came in on time and while I did my best to raise the quality of the code base and solve the performance issues (which is hard when the product ownership prioritises the wrong user groups) the company folded in March 2016.

It felt like I had failed massively at the time as I was personally invested in turning the product around but most of the actual issues were out of my control and I think as a leader I did right by my team ensuring that everyone was able to learn from the experience (we held some really good retrospectives after) and they all went on to work at some really interesting companies.

I struggled to find a job myself in the month the company folded, until my current employer picked up the project as I appeared over-qualified for a Junior Developer role but not experienced enough for a Senior Developer or managerial role.

It was also around this time that I decided that a career change into test automation wouldn’t actually be so bad as I had built two automation suites in two languages and this work would keep me in the quality improvement mindset I had enjoyed as a Software Development Manager.

Challenges

• Establishing quality gates— Before I took on managing the team the SDLC consisted of cranking out code as fast as possible, pushing it straight to master and then hoping the single tester caught any bugs in regression, after there was a Definition of Ready, Definition of Done, linting, automated testing and a git flow branching set up that meant we could develop with less risk
• Building a team of ‘Developers’ — Never having been taught what a ‘Developer’ was before I had to learn this myself and then getting others to see the value in seeing their jobs while developing a product and not just churning out tickets, The Phoenix Project was a real help here
• Validated learning — This was the biggest challenge for me, after setting up all the quality gates around the SDLC it became apparent that all the bugs being discovered by the client weren’t failures in the product’s code but failures in the product’s ability to meet the needs of the actual user (the nurses, not the management that we were targeting), I never really saw the change I wanted

Fuck ups & lessons learned

Hiring my friends
While I ultimately didn’t make the call on hiring any of the friends I ended up working with at the company I ended up working with three of them, one blames me for being fired and no longer talks to me.

Before I lead the team I had suggested the company interview a friend of mine that I went to college and university with who was looking for work and might be a good addition to the team, as someone focused more on the UI / UX side of the product.

Initially things worked well, there were only a few issues we had which were mostly due to me trying to share my experiences when I saw him doing things that had burned me in the past but I never really pushed it, apart from a very heated argument about the use of vector graphics over raster graphics for print work.

Unfortunately as I moved into the management role things started to become a bit stressed as the more I learned about UX the more I asked to see the research behind some of the solutions he presented and the value these would bring to the end-user.

I really wanted to push forward with a UX overhaul of the app, making the app fit the needs of the nurses who would be using it every couple of hours as they did their rounds but my friend was churning out UI changes with very little indication of the value this would bring and it seemed more like polishing a turd than tackling the major usability issues the app had.

Ultimately a business trip to Brussels resulted in my friend falling out of favour with the company and he was let go shortly after.

The lesson I learned from this is that you shouldn’t mix friendship and business because your friends might have expectations of you due to your existing relationship and business has different rules to those outside of work.

Ultimately I chose to push someone who was looking for leniency due to being a friend and this was perceived as hostility.

Accidentally re-provisioned the business’ CRM
One of the strengths of Odoo is that it basically does everything. If you can think of something you need to help run your business it’s highly likely there’s a module you can install to do just that so we used it internally as a CRM, Kanban board and pretty much everything else.

One of the weaknesses of Odoo is that it’s ridiculously easy to drop the database and reset an instance into ‘demo mode’. It’s even easier to do this when you write an Ansible playbook to do so and the only difference between the hostname of the UAT and internal business instance is a single digit.

Luckily Odoo is also really easy to restore and while I was panicking DevOps just laughed and told me it was a good exercise to test the backups which it turned out had been run an hour before I ran the script.

That day I learned the importance of having back ups and making sure they’re working as you never know when you’ll need them.

Software Developer/SDET/Cell Lead — BJSS (2016 — Present)

Towards the end a number of external people came in to see if they wanted to invest in the company or buy it and one of those visits was from someone I now work with at BJSS.

BJSS does a lot of public sector work, especially projects for the NHS, so it was a good fit for them to continue the development of the electronic observation product that we were building after the company folded.

For almost two years I continued to work on the electronic observation product as a developer in a new BJSS team, initially working remote from London before moving up to join the team in the Leeds office and while it had it’s challenges, namely being the only product team in a project based consultancy it was great to finally work with people who had the same ‘developer’ mind set I was building in the team.

Unfortunately for the team however the Product Ownership came over too which meant that I was still fighting that uphill struggle to get him to understand the real user of the product and the value it was providing them in it’s current state.

This uphill struggle was made harder by the fact that the team were only ever funded to carry out specific work such as adding new observation types to the product and they were never given time to address the real issues.

I had floated with the Project Manager that thanks to some changes in the networking requirements for health apps we could build a more scalable product by allowing NHS trusts to self-serve instead of building custom deployments whenever money appeared, but this didn’t go anywhere.

In February 2018 I was asked to go to a hot-house development sprint at one of the gambling companies in Leeds for what I was told was going to be a two week engagement but it turned out to be a year and a half!

I wasn’t very happy about this placement, not only because of my personal dislike of gambling but because I also lost any of the autonomy I had and was instead just there to write code with no say on the implementation details.

After a while I noticed that I spent a lot of time working with the testers on the team to help them build their automation framework and I decided that I could use this role to move from development where I saw no value in the work I did to being an SDET where I could at least deliver some value making sure that the team were meeting the regulations of the market.

After the gambling project closed down due to running its course I was then moved onto my current engagement as a Cell Lead on a big project working for an opticians.

My current role is probably my favourite, it has definitely had it’s issues due to inheriting a lot of legacy code but I’m back in the healthcare domain (although it’s mixed with commerce this time) and I’m leading a team again.

I’ve also finally worked with a BA that has made me realise the value a BA brings to the team as previously I’ve worked with BAs who have only really ever recorded requirements but never really had any interest in seeing the stories through to deployment.

It’s been refreshing to work with this individual as it’s allowed me to see how the role of the BA works within the bigger picture of software development as a whole and as we start to introduce more and more quality into the codebase they’re going to be key in helping build up the shared understanding needed to do this.

Challenges

• Not being a ‘programmer’ — When I first started at BJSS I felt very out of place as the types of developers I was meeting seemed to be very into Computer Science (‘programmers’) and I was more interested in development as a means to build a product (a ‘developer’). I no longer feel this way as the BJSS management team have done an amazing job of de-siloing the organisation’s role and promoting being ‘T-shaped’
• It’s a consultancy — I joined BJSS to continue working on the product I worked on previously and as such I was shielded from the fact that I was working at a consultancy where projects can be short-lived and resource reassignment happens frequently. Being ripped from my nice project to work on one I didn’t like was the point that I realised I work for a consultancy but that business model has it’s own rules to play within that I’m adjusting to.
• Working with contractors — Before I worked on the gambling project my experience of working with contractors was minimal and it’s been interesting to see the differences in how they all approach their work, some have been really great teachers and opened my eyes to managing work and others have been so stubborn that it’s been fun to watch them stew when presented with opposing viewpoints

Fuck ups & lessons learned

Assuming that your previous work is worthless
When the BJSS team first started to take on the old codebase there was a lot of domain knowledge to get them up to speed on and as they started to review the existing SDLC and the quality measures in place it became apparent that certain aspects didn’t meet their standards.

At the startup we didn’t have an experienced tester, we had a person who had come in as a developer and was assigned the role of a tester because their development skills weren’t as strong as the team had hoped but they didn’t want to fire them.

That being the case the testing was mostly a suite of happy path regression tests and automation that was built out of me learning about BDD and Living Documentation and wanting to use this to build the app.

So when the product was taken on by BJSS and the tester on the team wasn’t impressed with the approach taken with the non-automated tests I assumed there would be no value in the automated tests.

I was wrong however, as two years later just as the team was wrapping up I received a Slack message exclaiming that they’ve just found a treasure trove of automated tests for testing something they found impossible to get product ownership to give a clear definition of functionality for.

Thinking you’re alone when you’re the sole tester in a team
On the engagement for the gambling company my first big project after moving to being an SDET was to build the an end-to-end framework to help validate the behaviour of a new sports data system.

The project had four developers on it and myself as tester, and there was no sprint zero to get a testing framework set up which along with me taking annual leave meant I was playing catch up with the developers churning through work while I was still getting started.

This gap and the fact that a full end-to-end took the best part of two months to achieve due to network issues meant that by the time I was in a position to automate the tests there were 44 stories I had to work on and I started to get stressed out as I assumed the it was all on me to get the stories shifted.

Fortunately for me, one of the developers saw the impact this predicament was going to have on the team’s ability to deliver and suggested the team swarm writing the automated tests in order to alleviate the bottleneck in the flow.

Of course this process wasn’t without it’s downsides as I now had a bunch of Java developers working with JavaScript on a framework that was at the mercy of different upstream and downstream services failing, but they really helped to fix the problem and I re-learned the importance of communicating issues to the team instead of assuming I had to fix them.

Ways I want to fuck up in the next 10 years

I’m hoping within the next 10 years to have had a great idea for a product and to have built my own business around that product.

That being the case here’s how I’d like to monumentally fuck up:

• I want to take a gamble on building a business and realising my assumptions about the problem I want to solve are wrong and then learn how to adapt to solve the problems I uncover
• I want to have a friend who asks me to take a leap of faith in their business venture, for me to have to bail due to workload issues and then kick myself when it takes off, but still be happy that it worked out
• I want to mentor someone and be really jealous when that person has a more interesting career than mine