When I was in my second year of university, one of my lecturers was very fond of reminding us about the importance of code quality and standards. "In the real world", we were told, "in the industry", you won't be able to get away with uninformative variable names. You will be shunned if you don't comment your code properly. Our assignments in that unit had to be perfect - no using int i=0; for a loop, it had to be int index=0;. Preparing us for when we left the nest, spread our wings and went out in to the wide open world.
Of course, that was just a fantasy. What really happens is that you graduate from university and go to a job at an established company. You spend your first two or three weeks going through the codebase, familiarising yourself with how it all fits together. The code is an absolute mess, naturally. Fifteen years of rapid, agile development has conspired to create the monolithic mess you see.
Most junior developers will probably baulk at the messiness of the codebase they've "inherited", and attempt to set it right. A noble cause, really, but ultimately futile. I've been there and done it myself. Hours and hours have been wasted re-writing, refactoring, and modernising code that has been working for the better part of a decade. Yeah, it's hard to maintain, but it works. Over time, the developer stops being a junior developer intent on shaping the world in their own image, and becomes a senior developer who knows which battles are worth fighting.
Learning how to mould your styles to the style of the existing codebase is a crucial skill for any developer. At almost every job you take in your career, you'll be adopting a terrible, shitty codebase held together with duct tape, and that's just part of the job. This isn't to say that change is impossible, it just takes a long time.
I think every software developer starts off their "career" with something like the above code snippet, and wonders what the hell it means. public static void main!? I remember seeing this code for the first time at the start of Introduction to Computer Science at uni, back in 2004. I didn't even really want to do Computer Science; I was originally doing a Maths major, and I needed something to fill in my elective units, so I thought I may as well put that towards another major. I grew up with computers but never really had any interest in programming, so doing CompSci at university really only happened because I couldn't think of anything else to do at the time.
Looking back at my younger self (and indeed most of the other young people in that first year of CompSci), I’m amazed at how difficult programming seemed. I would struggle for hours just to put together a simple assignment, an assignment which would be about solving some trivial problem. As an example, one early assignment required us to implement a basic "change-giving" algorithm for a vending machine. Given a certain amount of money and an item price inputs, we had to calculate the correct amount and denominations of coins to dispense as change. I worked on this problem for weeks and couldn't find a way for the code to calculate the correct output. So, in a last ditch effort to "solve" the problem before I had to submit the assignment, I used a giant switch statement for every possible combination of change to dispense. Terrible. Terrible terrible terrible.
Thankfully I got a bit better over time, but by the time I finished the degree I still didn't really think I would cut it as a programmer. The course seemed to teach us all little bits and pieces from many different areas of computer science, but I really had no idea how to put it all together for the real world. I’m not sure how much CS degrees have changed in the last few years, but I would hope they have more focus on real-world applications.
Getting a real programming job, joining the industry, and putting my skills and education to use in actually creating software used by thousands of people every day; this has really been the catalyst in kick-starting my programming career. When you spend most of your day, five days a week, pushing out code for software that actually makes money, that’s what really ignited the flame for me. Since then I've spent a lot of my "off hours" reading tech blogs, learning different technologies, and creating my own side projects. Software development, for me at least, is about constantly learning. I consider myself very lucky to get paid to do something that I genuinely enjoy and am very passionate about.
I’m starting this blog so I can hopefully start to give back to the software community. For years I've read and been inspired by blogs such as Coding Horror and Chase Seibert. I want to start putting my thoughts and experiences out there so that others may stumble across them one day and hopefully find them of interest.