Feeling like an engineer
Wednesday was a turning point. I actually felt like a software engineer for the first time in my life.
Before the final two-week engineering project that caps off the course, there’s a week of individual effort. Tech tests. Stress inoculation for a ubiquitous feature of hiring in the tech industry. The exercise itself was extremely straight forward and could be coded (via spike) in about half an hour, but that wasn’t the point.
The point was to deal with it like an engineer.
The point was to bring everything learnt thus far on the course to bear on one point, like the tip of an arrow. Planning, modelling, OO principles, test-driven development, assertive debugging; do all that and produce something that you’d want to flash at an employer’s face as if to say, “This was I, and I was great”.
Admittedly, a personal sense of professionalism and confidence has been totally lacking up until now. In my head I was still very much a student, dabbling with a subject that will always be more than a lifetime’s study, which lead to the inevitable question: how exactly am I ever going to get hired? I wouldn’t hire me.
That changed yesterday. Following a false start at end of play on Tuesday when I realised I’d massively over-abstracted the problem, I re-modelled it that night and rewrote it the following day. No drama — this happens all the time, and the nice thing about software is that it’s easy to change. That’s precisely why the industry has moved to paradigms like Agile. I was told by one of the coaches that software used to follow traditional engineering practices, in that you’d wring the client dry of requirements in endless meetings and months of planning. While that approach is appropriate for things like bridges and skyscrapers, structures notoriously reluctant to move once built, software is ultimately words on a screen. When that was realised, Agile was born.
And it worked. The code worked. It was a day of work that didn’t feel like groping for a black cat in an unlit coal bunker. I knew what I needed to do, in what order I needed to do it, and what tests to write. There was one bug right at the end of the day that a colleague eventually solved (thanks, Kate), but up to that point I’d followed a structured debugging process and knew what was failing (just not why).
More importantly, though, I’d produced code that I wouldn’t be ashamed of showing someone.
Simple, yes.
Ashamed: No.
