The Green Coder [Issue #2] - Building your engineering tool chain

This is an archive version of issue 1 of The Green Coder, a short experiment which has since morphed into The Fresh Engineer Podcast. Check it out for a continuation of these thoughts!

It's week two so that means we're on a technical topic today. I wanted to kick off with a topic that will begin for you in your pre-professional days and won't end until well after you retirement. The tool chain you use and make your own is one that will be of constant debate amongst you and your future colleagues. It'll be one of the most divisive and personal topics, and it'll also be one of the most fun.

In software engineering we're fortunate to, usually, be able to choose our own tools. Many are free, and others are often inexpensive. With this choice comes freedom and responsibility. Today we're going to talk about the common types of tools you'll need to use, how to choose which ones to invest time into, and a couple pitfalls I see newer engineers struggle with.

Aim to be agnostic, but ensure you learn one well

Far too many people get married to their tools, this is not noticeable when you have the luxury of working on your own machine. However, when you try to help out a new colleague with some tasks on their machine, you're going to wish you were more comfortable working across different operating systems and text editors.

Your end goal should be expertise in your chosen core tool chain, with a broad working skill set across other standard options. In other words, you want to be a "T Shaped" individual. The top cross of the T represents breadth of understanding across a subject area, the vertical line down represents a depth of skill in a particular area. This should be the long term goal of your skills with various tool chains. To give you an idea, here is my T shaped tool chain.

Some of my chosen daily drivers:

• Emacs / VS Code.
• Zsh with my personal configuration files.
• Git  on the command line.
• FireFox as my web browser.
• Curl the industry standard cli http client.

Other tools I have working knowledge of and can comfortably use:

• Notepad on windows, vi and nano on linux.
• Any Jetbrains IDE and Visual Studio, a popular .NET IDE.
• Bash - the most common shell on linux systems.
• PowerShell and cmd - common shells for windows.
• I can use the dev tools reasonably well in Chrome, Safari, and Edge.
• Postman, a cross platform http client.

With these tools I have some which I'm fast at using and can make use of advanced functionality, but I'm also not paralysed the moment I have to SSH or RDP onto a more minimal system. I can also get things done quickly on a colleagues machine if needed.

Avoid the OS wars

Younger me was quite dogmatic about which operating system was superior. As time has moved on, I've dropped this and I spend my time using Linux, Windows, and MacOS every week. The key thing that swayed me is the fact that there are many operating systems and as an engineer you will be forced to work on different ones throughout your career.

These days I'm not as agile with Windows as I used to be, my powershell-foo is not what it used to be. But I work across linux, mac, and windows most weeks due to the demands of the business I work in. I love discussing the pros and cons of operating systems, and there are aspects of some which drive me insane, but it is really important to realise quickly that you'll be better at your job if you can confidently work across them all. That's not to say you need to learn each inside and out, but in the first few years of your career you should try to spend some time learning the basics of mac, windows, and a linux system or two.

Common tools you'll need

Okay, so what is the base minimum toolchain you should be thinking about in your first few years? I think it's important to keep it really simple, and much of it will depend on what you're building. Here is a list of what I would suggest builds the foundation of your toolchain.

• Editor / IDE - You'll use for 85% of your work so it's important to learn one well over time. Try to understand the shortcuts and move away from the mouse when doing most of your tasks.
• Email client - This one might surprise you. Email is definetely a bore, but let me tell you. The longer you're at an organisation, and the more senior you become in your career, the more email you'll be dealing with. Treat an email clinet like your IDE, choose one, and learn it's advanced functionality like inbox rules. If possible, find one you can extend with scripts. Don't go overboard on this, Thunderbird is a great option. Many times you'll be stuck with gmail but even that can still be quite powerful.
• Shell - Use something simple and common but learn it well as you'll likely find many problems become simpler when they're in a shell. I wouldn't muck around too much with shells like zsh, or fish to start with unless all the senior folks around you are doing so. Stick to the defaults, they're just as powerful as anything else. Powershell, and Bash are great places to start.
• Operating system - This is as much a tool as anything else, make sure you're comfortable with a spread of options but commit to one to be an expert in. If Windows is your thing then that's great, as long as you're ready to hop on a linux box every so often. If you're you prefer mac, just make sure you have Remote Desktop ready to go to debug issues on a Windows server.

How to choose your brand of tools

My number one piece of advice for you when choosing tools is simple, use what the senior engineers around you are already using.

Use what the senior engineers around you are using.

Put aside everything else in your first job, and commit to using what the senior engineers are using. You might have a couple weeks of pain trying to learn the interfaces, but the moment you need help you'll have it from people who've been spending the best part of a decade using that particular piece of software.

The approach of using what everyone else is using won't be one you use forever. You'll find that as you continue over the next couple of years in your career, you'll want to start choosing tools that fit you a bit better. That's where my next few pieces of advice come in, but I want to stress the first point. If you're new to a technology or type of tool, just use what your team and seniors are using, it's a great place to start!

So you're past that point and now you're starting to make your own choices. My next category for choice is "flexibility", you want to choose a tool which will work in a variety of scenarios and tackle several tasks. By doing this you reduce the amount of tools you need to learn and you leave more room in your brain for the hard stuff. Be careful not to confuse multi-use and flexibility with "highly configurable". Configurable tools are often ones which give you a lot of flexibility, but they can also be traps ready to snare you and drag you down into the Wonderland of configuration.

Question your past choices

The tools you choose today may not be the best tools for you tomorrow. I would suggest spending a bit of time once a year critiquing and re-evaluating 1-2 of your tools. Is vscode the right editor for what you're doing now? Maybe you're better off with a more complete IDE. After doing this a few times for a given tool you'll hopefully find yourself settling on longer term happiness with that choice. This is when yo uknow you've hit the sweet spot!