I’ve been working as a firmware engineer and a technical leader for a relatively long time now, and certainly long enough to have made my fair share of mistakes. Over the years, I’ve made errors in coding, architecting, planning, testing, reviewing, communicating… the list goes on — but I’ve learnt something from every single one.
I wouldn’t be the professional I am today without the experience gained from making those mistakes and working through them. I owe a fair chunk of my professional development to my own tenacity to improve, but I owe a far larger chunk to the peers who have helped me along the way. Whether to highlight an obvious coding booboo when I was starting out, to explain an architectural oversight as I was maturing or to help me phrase a better customer email when I became client-facing, the contribution that each and every one of these interactions will have made to my professional growth is not lost on me.
So, in the spirit of community and to give something back, I thought I’d write a little series of articles to collate some of the wisdom I’ve absorbed since I started my career. My goal is simply to share some experiences from my professional journey in the vague hope that in some way they might have a positive impact on someone else.
So, without further ado…
Sharesies #1: Know Your Environment
When starting a project, we either join something that’s been running for a while or start something new. If the former, we all instinctively understand the need to ‘get up to speed’. We allocate time (and sometimes an inordinate amount of time) to get to know the environment we’ll be developing in. We make sure to find out where all the skeletons are hidden and how to dust them, we poke about in the attic and we rearrange the furniture for funsies, even though no one asked us to.
Yet peculiarly, when starting something new, and particularly when we’re responsible for laying the foundations and making the initial contribution, it seems our standards can slip — “It’s a new house, there can’t be any skeletons, I don’t need to look upstairs”— we don’t tend to allocate the requisite time to prepare a new development environment as thoroughly as we critique an existing one and, as a result, it becomes all too easy to make poor decisions that can see a fledgling project off down a bad path.
I can’t tell you the number of times that I’ve joined a software project and it’s been immediately clear that the entirety of the application has stemmed from a bastardised tutorial. This seems to occur quite frequently in firmware and embedded software, and I’ve seen a fair few consumer products underpinned by source code that has been quite obviously hacked to fit into the framework of a vendor example or snippet. When I see projects like this, I see it as a sign that the founding engineers didn’t take the time to consider the requirements of their development environment within their project context to sculpt it accordingly, and so I proceed with caution. I’ve learnt that this kind of seemingly innocuous non-decision can lead to incredibly painful project migraines that have a tendency to strike without warning and at the worst possible moment, usually just before a demo.
What am I building? How will it be deployed? What’s the shelf-life? Will something else need to use it? Will it be customer-facing? Will it be public? For software projects, it’s the answers to these types of questions that help us design and construct development environments suitable for any project and that will actually assist in its smooth delivery, rather than being a constant pain in the ass throughout its lifetime.
For example, am I building an application or a library? I know that the answer to this simple question will almost certainly affect how the software is best deployed, and from painful experience, I know that how software is best deployed is quite likely to be affected by things as trivial as, say, folder structure. Aspects like folder structure, file paths and file naming are invariably decided when a project starts and are generally a total nightmare to change once a project is running, so it pays to give them due consideration within the right context when it’s cheap to do so; at the beginning. Similarly, the answers to other questions will bring further decisions to the surface, and with every small decision made and not ignored, the development environment will become better tuned for the project, and life becomes easier.
Nobody wants to be the poor bastard who has to work a Sunday fixing some massive structural problem with the build pipeline that could have been avoided with an extra minute of forethought when the project started, so know your environment.
