Previous | RSS | Next
My journey in code
This post was inspired by another one I stumbled across by chance during my normal internet activities. You can see the original here: https://dev.to/laraneedscoffee/my-journey-in-code--24k1
1. High School and Code
Coding didn't really happen during the early-to-mid '00s in British schools. When I was going through secondary school we were taught how to use Word and Excel... and that was it. In fact, we got yelled at if we tried to run code we'd written on school computers. I suppose in many ways this was good practise for learning to live under a corporate IT policy!
I taught myself to code at the age of 15 by copying Tim Anderson's VBA tutorials from the back of Personal Computer World magazine. I also experimented with Game Maker and Dreamweaver on an old skip-rescued Compaq machine running Windows 98 SE, then later the family desktop running Windows XP.
2. College Code and Tears
Unfortunately the British definition of "college" doesn't match the American one, so to clarify I did a BTEC ND at a sixth form college instead of three A Levels at secondary school, then went to university afterwards.
At my sixth form college I was taught VB.NET 2005 and ActionScript, but I also bought a big-ass book on C++ on my own initiative and worked through that in my spare time. I also wrote the initial versions of Bob's Tech Site by following books on AJAX, CSS and PHP. This was also when I started using Linux for the first time, so while the college machines were running Windows XP I dual-booted Vista and Ubuntu at home.
At university I was introduced to C# in the first year of my Computer Science degree and Java in the second. The first year was fairly easy because I'd already learned the material in the BTEC ND I'd spent two years doing beforehand, but in the second and final years I covered more advanced subjects. I remember doing a module all about rendering 3D meshes with DirectX 10 using C++ (we were expressly forbidden from using XNA), while other modules covered subjects like developing Android apps, cross-platform development with Qt and Oracle PL/SQL and APEX. I also paid for an optional module so I could learn how to develop apps for iOS4, only to discover the Mac Mini I'd bought couldn't run XCode when Apple added Storyboards to it for iOS5 (sigh).
I finished university with a very comfortable 2:1. I got a 1st for my final year project and most of that year's modules, so it's possible I would have done even better if I'd concentrated more in the second year (where I scored a 2:2 overall!). But I'm still happy with the final result, particularly given the amount of scepticism I faced in 2009 when I first said I wanted to do a Computer Science degree.
3. Work and code
I joined the BT TV team via BT's graduate scheme, and my main job there was to write Java middleware applications that would run on Oracle WebLogic. I actually spent most of my time volunteering to teach kids to code, writing Python (a language I learned on the job) and creating a back-end system for Silverlight media streaming using C#.
After 3 years I moved across to Capgemini and spent 12 months building Java middleware services. However my previous Java knowledge was of limited helpfulness because they were based on Apache Camel, Blueprint and JBoss Fuse ...all of which were completely new to me and required me to write Java in pre-prescribed ways! Thankfully it didn't take me too long to get up-to-speed.
On the new project I moved to this year I found the knowledge I acquired last year was of limited helpfulness because... I'm working with a technology I'm not familiar with that requires me to write Java in pre-prescribed ways. In this case it's building middleware APIs on top of WSO2, and I'm hopeful it'll (fingers-crossed) take less time to get up-to-speed.
Conclusions I've drawn
Based on my own experiences:
- IT education in Britain is much better than it used to be (See Barefoot, YRS, Raspberry Pi & Micro:Bit)
- Everything you learn has a very short shelf life, and there won't be enough hours in the day to learn everything
- This means you need to use your judgement with the latest "flavour of the week" languages and frameworks to determine if they're worth learning and/or if you can have a viable career using it
- Most of my job is learning new things and trawling through the log files of an unfamiliar system to figure out "is it a bug or a dodgy config?"
- Your favourite programming language is probably not the one people will actually pay you money to build things with. Save it for the side-projects
- WHY DOES JAVA HAVE SO MANY FRAMEWORKS THAT DO EXACTLY THE SAME THING?!
- WHY DOESN'T JAVA TRUST ME TO CODE THINGS PROPERLY?!
- It's fine Java, I love you really. I can't really hate a language that's paid my bills and introduced me to a lot of cool people
If you're a new developer, here's the world-wearied advice of someone who's been working this gig for nearly five years now:
- If you come from a working class background like I did, avoid going the UCAS route to university if you can. Find yourself an apprenticeship with a good employer where you'll gain experience, a full-time salary and a degree without being saddled with debt that takes hundreds of pounds a month out of your monthly wage packet for decades
- Don't get too comfortable in your programming job, because you will be moving around every 2-3 years. Loyalty is rarely rewarded and there's a chronic skills shortage, so job-hopping and freelancing is a pretty standard practise for talented software developers
- There's always one person on the team who's been there since the dawn of time and has a god-like ability to fix all that they touch and complete half the sprint backlog in a single afternoon. Learn as much as you can from them, because not only is it good for your career it will also save the team if they ever decide to leave for greener pastures, get run over by a truck or ask to book two weeks' annual leave
- Never underestimate other peoples' ability to fill your Outlook calendar with meetings (direct them to Slack or agree within your team who the best person to send or dial-in is so you avoid too much lost development time)
- Also never understimate other peoples' ability to fill up your work email inbox (automated mailbox rules & auto-archiving keep me sane)
- Learn how to use the Atlassian suite. JIRA will crush your soul and sap your very life essence, but the industry has standardised on it to help clients and middle managers understand what we're up to. Plus, all the project documentation is probably on Confluence because it's less painful to use than Sharepoint
- Make sure you get out and smell the roses once in a while, and don't linger in a bad situation for too long. "Burnout" is a real thing and it is less than pleasant, so you should ensure you work your contracted hours and have hobbies that aren't just an extension of your normal day job
Doing the job
- Avoid making assumptions, because they nearly always turn out to be completely wrong. "Common sense" is entirely subjective!
- You shouldn't criticise your predecessors when you join a new team development project. Decisions you perceive as "bad" may have been considered good practise at the time, or were probably the least-worst work-around for previous bad decisions and poorly-conceived company policies
- If you think Subversion, Perl, Pascal, Internet Explorer, COBOL, Flash, Silverlight, SOAP, Apache Struts and/or Windows Server 2003 are all dead then you are in for one hell of a surprise
- Almost no one follows "true" agile because it's often incompatible with existing business processes and most organisations prefer to make less-risky small incremental changes rather than wholesale process changes that will encounter resistance. Unless it's a greenfield project that just your team is working on you'll likely have to compromise by pretending Scrum + Waterfall = "agile"
- Everyone wants to (and definitely should) follow TDD and BDD, but you'll hear a lot of excuses for why people are using stacktraces and logs instead. It takes work to do things right, but it's worth it. Be prepared to work in teams that "don't follow good practise yet" though
- Finally, always be open to the idea that you're wrong because it'll happen more often than you think. There's an industry-wide crusade against the so-called "brilliant jerk" that ruins development teams. Don't be one of those!