💾 Archived View for gem.trechnex.com › posts › code-journey.gmi captured on 2023-05-24 at 17:48:47. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

My Journey in Code

3rd March 2018

Introduction

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 did not 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 had written on school computers. I suppose in many ways this was good practice 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 6 and Dreamweaver 8 on an ancient Compaq machine running Windows 98 SE, and then later the family desktop that ran Windows XP.

http://www.itwriting.com/blog/

https://en.wikipedia.org/wiki/Personal_Computer_World

2. College Code and Tears

Unfortunately the British definition of "college" does not match the American one, so to clarify I went to our equivalent of a community college, and then went to university afterwards.

At my "sixth form" college, I was taught VB.NET 2005 and ActionScript, and I also bought a big-ass book on C++ on my own initiative and worked through that in my spare time. I also wrote my first blog posts for "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 straightforward because I had already learned the material at sixth form college, 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 with APEX. I also paid for an optional module so that I could learn how to develop apps for iOS4, only to discover the Mac Mini I bought could no longer 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 is possible I would have done even better if I'd concentrated more in the second year. But I am still happy with the final result, particularly given the hurdles I faced in 2009 when I first said that I wanted to do a Computer Science degree.

3. Work and code

I joined the a telecom company'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 an IT consultancy 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 was working with a technology I was not familiar with that requires me to write Java in pre-prescribed ways. In this case it was building middleware APIs on top of WSO2.

Conclusions I have 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 are 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?" rather than writing code
Your favourite programming language is probably not the one that 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 cannot really hate a language that has paid my bills since graduation

Bonus Advice

If you are a new developer, here is some world-wearied advice from someone that has been working this gig for nearly five years now:

Career advice

If you come from a working class background in the UK like I did, avoid going the UCAS route to university if you can. Find yourself an apprenticeship with a good employer where you can 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
Do not get too comfortable in your programming job, because you will be moving around every 2-3 years. Loyalty is rarely rewarded and there is a chronic skills shortage, so job-hopping and freelancing are a standard practise for talented software developers
There is 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, but 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

Workload management

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 to avoid 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 is 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 about existing systems, because they are probably wrong. "Common sense" is entirely subjective!
You should not criticise your predecessors when you join a new team development project. Decisions you perceive as "bad" may have been considered good practice at the time, or were the least-worst work-around for previous bad management decisions, or 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 is 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 is a greenfield project that just your team is working on, you will probably have to compromise by pretending Scrum + Waterfall = "agile"
Everyone wants to (and definitely should) follow TDD and BDD, but you will hear a lot of excuses for why people are using stacktraces and logs instead. It takes work to do things right, but it is worth it. Be prepared to work in teams that "don't follow good practice yet" though
Finally, always be open to the idea that you are wrong, because it will happen more often than you think. There is an industry-wide crusade against the so-called "brilliant jerk" that ruins development teams. Do not be one of those!