A classic route into programming is a childhood encounter with a computer. You realize it's your passion, so you go and study computer science and head off to build the next amazing software product. That's not how it happened for me. Instead, it came as a surprise.
My history of history
I wanted to work in Museums and Archaeology. History fascinated me, and I imagined being in charge of a museum collection. The hitch in the plan was that my college didn't offer the right courses.
Studying courses that didn't excite me was a dead end, so after a year, I quit and got a job. After bouncing around for a while, I found myself in the finance industry and soon created my first piece of "Shadow IT". When my team leader taught me to calculate pension contribution limits by hand, I built a spreadsheet to automate the process. Then I did the same for the trickier issue of Income Drawdown calculations.
Eventually, I landed in compliance (how this happened is a story in itself, but let's press ahead). One of the tasks I picked up was to create an internal web-based knowledge base. So, I learned the web stack just as it was getting interesting (iframes, AJAX, and browser wars!)
A new dawn
Then Project Aurora happened. The kind of project where they spent far too long deciding on a name and not enough time thinking about how it might bankrupt the organization. A massive, one-shot, big-bang replacement system that would, of course, never reach production.
I joined as a compliance advisor and, thanks to a contingent of developers from the West Midlands, left with the ability to write code and design database schemas.
Taking the bit between my teeth
When the project collapsed, those of us who had been seconded and back-filled ended up in an exit-lounge collective cheerfully called the Business Improvement Team, or "BIT", as in "we're going to get rid of you all in a bit."
My boss, Nigel, assigned me to a software project that the IT department didn't like the look of: a file-tracking system. It was supposed to be a six-month project.
Not knowing the Project Management Book of Knowledge (sic), I just set up shop in easy reach of the filing team, learned what their challenges were, and showed them each day my progress on the file tracking system. After a few weeks, we had a system that solved all their problems. We were done.
The IT Manager pulled me aside and told me the project had impressed them and that they were transferring me to their team. There's a chance that the fast delivery and delighted users caused some embarrassment, and the transfer was designed to shift the achievement into the department. The developers certainly made it clear they didn't want me around, and my lack of formal qualifications came up many times.
This would have been a disaster if it weren't for SW, a contractor who helped me apply what I'd learned from interpreted languages to the cool new thing, .NET. Having previously written database connections, queries, and web front-ends by hand, the design surfaces that represented the "new way" in .NET were unfamiliar and felt clumsy.
With the help of SW and a solid stream of incredibly thick books from the local bookstore, I expanded my skills and knowledge enough to work on some complex real-time trading apps.
The staircase up from vernacular development to disciplined delivery was made from the crushed bones of the challenges I faced in those two early projects and my transition into a role on a software team.
What I learned along the way
Let's switch to snappy sentences to summarize some of the key things I learned as I bumped and scraped my way into a career in software.
First and foremost, a computer science degree is not the only way to become a developer.
The big bad project
The first software project I worked on was a disaster, and that taught me to respect a lot of things.
The bullshit culture of some software teams means nobody is honest about what's going on. When people get punished for flagging a problem, they keep quiet. This is the leading cause of software disasters.
When you look at an awful old system and decide to rewrite it, you'll fail. That system contains crucial knowledge that will only emerge late in your replacement project.
If you look around the room and find more people coordinating the work than doing it. It's time to get out.
The small successful project
The second software project I worked on was a resounding success, and that taught me many amazing things.
The best design for a software system will emerge when you work every day with the people you are building the software for.
Working in small batches stops you from going too far down the wrong path and is a direct enabler for showing your users your work every day.
When you work in small batches and get daily feedback, you avoid a huge amount of work you don't need to do. In my case, the software was done in one-twelfth of the planned time, because we decided we didn't need eleven-twelfths of the features.
Surrounded by knowledge
We are all surrounded by knowledge. Every developer has tackled different challenges, so we can all learn from each other. Solving problems together amplifies our knowledge.
Whether you have a related qualification or not, never stop learning. Every time I pick up a new technology, I get books and search out the people writing or talking about it.
Honestly. Books. You can quickly skim in knowledge to solve an immediate problem, but books stick around in your head for years and solve thousands of problems.
Alternate your reading. Read a tech book, read a novel, read a book on culture or leadership. The social side of software is inseparable from the technical side.
Keep a journal. These days, that's often a blog. Write down how you solved a problem so future you can look it up and save time. Your writing is a form of extended memory.
CODERLEGION
... and that's what brings me here! Sharing perspectives with an amazing group of software developers with different backgrounds, different experiences, and different puzzle pieces that we can bring together to form some great knowledge.
You can find more origin stories here (and add a link to your Coder Legion origin stories in the comments so I can read more!)
Why Every Computer Programmer Needs an Origin Story by Dave Schuster
Every Programmer Has a Starting Point - Here’s Mine by The Duchess of Hackers
