Codeslinger

A bit ago (around 5 years at this point), a relatively senior manager said something interesting to me, in the context of a software company. I had just started working in a new area, effectively, and this person was a senior director in charge of all software development efforts for that part of the company. He said (and paraphrasing, to be clear): "we want to ensure that we do not have any extra code in the codebase which is not needed for what we are shipping". This struck me as somewhat odd at the time, and still resonates as counter to how I would run a software organization... and in this blog post, I'm going to try to explain why, as best I can. To start with, I suppose, this is not really a sentiment which is expressed much within smaller organizations, which had comprised the majority of my professional career to that point. In a small company, you're just trying to ship products that people want, and/or optimize your time to market, and rarely have the time ...

Allow me to posit a hypothetical. Imagine you are at a company, and someone (perhaps you) has just completed a project to implement some complex feature, and you have been tasked with ensuring the implementation is documented, such that other/future developers can understand how the implementation works. For the sake of argument, we'll assume the intent and high level design have already been documented, and your task is to capture the specifics of the actual implementation (for example, ways which it diverged from the original design, idiosyncrasies of the implementation, corner cases, etc.). We'll also assume you have free reign to select the best tooling, format, storage, etc. for the documentation, with the expectation that all of these are considered in your work product. Note: This is, in my experience, a not uncommon request from management, especially in larger companies, so it seems like a reasonable topic for general consideration. Let's see how it plays out, look...

One of the more insightful conclusions I've reached in my career, if perhaps also one of the more controversial opinions, is that you should always say "no" to code freezes (at least in an optimal development methodology). This isn't always possible, of course; depending on where you are in influence and decision making, you may have only some, or effectively no, input into this decision. However, to the extent that you are prompted with this question and have some input, my advice is to always push back, and I'll elaborate on this below. The case for code freezes I've heard a number of different justifications for why people want code freezes, and these desires come in a few forms. Some examples: We need a code freeze We need to defer some code changes for a bit, just until... We need to hold off on this going in because... We have a release schedule where no changes go in during this period etc. Typically, the justification for the ask is achieving some desi...

Almost every time I scroll through LinkedIn, I run into one or more posts with some variation of the following: You're wasting your life working for someone else, start your own business... Invest in yourself, not traditional investments, so you can be super successful... [literally today] Don't save for retirement, spend that money on household help so you can spend your time learning new skills... etc. These all generally follow the same general themes: investing in yourself allows you to start your own business, and that allows you to get wealthy, and if you're working a 9-5 and doing the normal and recommended financially responsible things, you're doing it wrong, and will always be poor. I'm going to lay out my opinion on this advice, and relate it to the career/life path I'm on, and what I would personally recommend. Let's talk risk The main factor that most people gloss over, when recommending this approach to a career, is the element of risk. When la...

Something I've been musing about recently: there's a pretty high value, for managers, in knowing the value of people within a business. I'm kinda curious how many companies (and managers within said companies) actually know the value for their reports, beyond just the superficial stuff (like job level). Motivating experience: people leave companies. Depending on how open the company is with departures, motivations, internal communications, etc., this may be somewhat sudden and/or unnoticed for some time. Sometimes, the people that leave have historical specific knowledge which is not replicated anywhere else in the company, or general area expertise which cannot easily be replaced, or are fulfilling roles which would otherwise be more costly to the organization if that work was not done, etc. Sometimes these departures can have significant costs for a company, beyond just the lost nominal productivity. Note that departures are entirely normal: people move on, seek other opp...

There is a language design principle in C++ that you should only pay for what you use; that is, that the language should not be doing "extra work" which is not needed for what you are trying to do. Often this is extrapolated by developers to imply building "simple" code, and only using relatively primitive data structures, to avoid possible runtime penalties from using more advanced structures and methodologies. However, in many cases, you can get a lot of benefits by using so-called "zero cost abstractions", which are designed to be "free" at runtime (they are not entirely zero cost; I'll cover the nuance in an addendum). These are cool, imho, and I'm going to give an example of why I think so. Consider a very simple, and somewhat ubiquitous in code from less experienced developers, function result paradigm of returning a boolean to indicate success or failure: bool DoSomething();  This works, obviously, and fairly unambiguo...