SW engineering, engineering management and the business of software
The last time I wrote about the tools I used was in 2011 (with a 2013 update). Quite a bit has changed and I think you are due for an update.
I still use the Mac. Specifically the 2018 variant of the Best Laptop Ever Made. It is starting to feel it’s age tho. I’m looking forward to the Apple Silicon transition, but I’m not going to jump on the first gen consumer machines. I’ll probably pickup one of the 16” pro laptops when they are released.
One thing that is different is that I have a proper standing desk, external monitor mounted on arms and other accoutrements.
In a fit of Handymanity I found a nice surge protector with mounting holes, went to the hardware store to find the exact kind of screws that would work and mounted it to the bottom of the desk. It works quite well and I’m irrationally proud of it.
I use an old iPad air (first gen!) with the old, discontinued TwelveSouth HoverBar 3 to persistently display a calendar. This is a huge part of managing my time. Having a persistent calendar view that can’t be hidden, covered or accidentally quit makes a real difference in my attendance and punctuality.
I started streaming recently and have updated my front facing camera game with a Panasonic GH4 and the Black Magic Design ATEM. I use a small clamp to mount the GH4 behind the monitor onto the mounting arm. It works surprisingly well. the lens of the camera is just above the top edge of the monitor and if I position the video conference window in the top half of the screen, the apparent eye contact is pretty good.
The GH4 is and older model, so it can be found significantly discounted from the original retail price. You can use it all day and the sensor won’t overheat. I also had some wide aperture micro four/thirds lenses lying around and the camera does a good job of adjusting auto-focus depending on my posture.
As of this writing, I don’t have a good mic yet, but I do like Podcastage’s reviews and will probably get something low-end on his recommendations.
These apps are my must haves. You’ll see quite a few repeats from my 2011 tools list.
I use 4 different web-browsers for different things:
My most used language in 2020 was Go. It’s still my favorite backend language, but it’s weaknesses are more apparent to me after building a large project with it as a single developer.
I started playing around with Elixir and Phoenix Novemberish, in public. It’s early, but I like it a lot so far and it challenges some of my expectations and assumptions about what a great programming language ecosystem can be.
Source Control & Diff
I also recently switched to zsh, the new default. After porting over my profile dotfiles and setting up history and autocomplete the way I like it, I can’t really tell the difference.
There are many data structure across the whole of computer science. As a developer, you only use a small handful for the majority of your work. A large handful are important enough to know about off the top of your head. The majority can be considered exotic and can be looked up when you need to.
This is a list trying to answer the question “What Data Structures Should You Know?” by bucketing them into roughly the categories above.
This is a general recommendation based on decades of engineering experience across a wide array of fields and industries, from semi-conductor to healthcare. Your industry will have different priorities. Graphs and ZDDs/BDDs become more important in if you work with maps, geo-coordinates, etc.
In some languages, certain data structures are more important. If your language’s native, internal implementation of an “array” is a linked list, you better know that linked lists take a relatively long time to count the elements in it.
As a hiring manager, Senior engineers typically shift up a level. the Must Knows become “Know it like I know how to spell my name” and the Should Knows become Must knows. For Hobbyists or Early Career Engineers the should knows tend to be more of a Lookup When You Need It. The Must Knows are always Must Knows. At any level, there is nothing that will disqualify you faster in a technical interview than using an array when you should be using a map.
This list is primarily geared towards getting day to day work done as an average engineer. It is unfortunately not sufficient for interviewing. Interviews are broken. If a company asks you to implement a red-black tree from scratch, I hope you are interviewing to work on complier or database internals or something, because that is rarely a useful question to ask.
Lastly, when we say “know” we don’t mean you need to know how to implement them from scratch. 1
Here are the general guidelines (barring any job/industry specific requirements):
“Know” means you should understand how they are used, what kind of problems they solve and have a rough sense of big O for time/memory/space for typical activities such as insertion, removal, retreival, search, etc.
“Be Familiar With” is having an understanding of the basic usage and properties of a given data structure. For example, Being Familiar With a stack mean a simple understanding of how a it works (LIFO array) and that push and pop are O(1) operations.
Most of the items in the “Be Familiar With” category aren’t that common with respect to day to day usage, but are fairly important when you need them. As a homeowner, you may not use a vice or clamp that often, but there aren’t a lot of good options if you really need one. It’s also likely that they are used under the hood of much of the tools and libraries you do use often.2
You may have noticed that the Caveat section is longer than the list itself. It’s quite subjective, but I’ve tried to focus on doing day to day engineering work. Feel free to hit me up on twitter @amattn if you have any feedback or suggestions.
It must be said however, that implementing a data structure from scratch is one of the best ways to learn that data structure. ↩
In the words of a dear friend, these are “shit you’ll use occasionally but damn well better understand because they’re not that complicated and are conceptual underpinnings of so much important shit” ↩