Reflecting on my growth as a programmer

One of the things I realized from dealing with that programming issue is that I don’t have a mature development workflow for front-end work yet. On previous projects, I focused mostly on back-end development. I had somewhat gotten the hang of test-driven development and code coverage when using Rails before, and I set up an issue tracker for my previous teams. For my main consulting engagement, I shifted to working on mostly HTML, Javascript, and CSS. I’d handled a bit of that before, but we usually worked with designers who did most of the heavy lifting (and the cross-browser fiddliness). Over the past two years,  I picked up more JQuery and Angular, fought with Internet Explorer 7 and then 8, and explored Chrome’s developer tools a bit more.

I didn’t have things quite set up the way I think other people have. I felt mildly guilty about installing programs that were not available from the client’s internal software site, although Emacs was definitely worth the twinge of unease. Even the version control I used was ad-hoc, using Git on my computer to manage snippets for copying and pasting. I still haven’t mastered the Javascript debugger in Google Chrome, much less the tools available for other browsers. (Hence all the grief Internet Explorer gave me.) I didn’t have a test framework set up, so I often committed regression errors and other mistakes. I haven’t yet internalized all the cool development tools in Emacs, like Smartparens and Magit. (I’m slowly getting the hang of multiple-cursors-mode, though!) In terms of workflow maturity, I felt more like someone a few years out of university (or maybe even someone in their final year of classes!), and definitely like someone cobbling things together instead of picking up practices from a well-running team.

My main consulting engagement is coming to a close, but I’m looking forward to learning more about the craft of software development. I have a few personal projects to practise on, and it might be easier to Do The Right Thing when you’re less worried about potentially wasting the client’s time. I’m looking forward to familiarizing myself with more of the nifty features in Emacs. I’m also looking forward to immersing myself in the right ways to do things with popular frameworks, including testing and deployment.

I’d like to become a good programmer someday. What would that be like? For the particular way that I work–a generalist pulling together different things quickly–a good programmer might be one who has a neatly organized library of snippets, and who writes modular code with simple tests that exercise different functionality. Using a debugger, the good programmer would be able to dig into other people’s code, figuring out even things that aren’t documented. That programmer would also be able to quickly prototype and build well-designed interfaces. Things don’t have to win awards, but the interface shouldn’t get in the way. An even better programmer would have the ability to coordinate other programmers, improving people’s results by helping them work on both a tactical and strategic level.

Someday!

2014-09-15 Reflecting on my growth as a programmer

2014-09-15 Reflecting on my growth as a programmer

  • Steve Dowe

    Hey Sacha, always love reading your posts when time permits!

    This one resonated with me quite a bit as, being a micro-business owner/manager/do-it-all type, I am “forced” to a certain extent down the same path of being a generalist. I know some JS, some PHP, 0.1% of Emacs, etc… It can be very hard to focus enough time on picking up all the technical skills necessary to “stay current”, especially when your competition might 10 years younger, brighter and less-fettered by life experience!

    In terms of your workflow not being mature, I would argue that it’s simply multifaceted and reflective of a creative mind – loosely coupled and flexible! ;-)

    I particularly look forward to more Emacs coverage – as always! – and following your approach to picking up new skills. Keep up the good work!

    • Aww, thanks! I really don’t have any excuse other than not having sat down, thought about it, and practised it relentlessly. My clients are already impressed by the speed of prototyping, so even if I do things a little bit slower in order to practise doing things the Right Way, they should still be cool. =)

      While writing this post, I discovered this odd little quirk in my mind about feeling fine with taking some billable time to learn client-specific things, but feeling just a smidge guilty about taking billable time to learn more generally-useful things. (Hah, maybe that’s another argument for shifting over to pricing for value instead of time!) It’s a silly distinction, since that general-purpose work will also save client time in the future and it’s all quite fungible anyway. So maybe I can push that boundary a little more!