Reflections on Software Performance — Nelson Elhage. The Product-Minded Engineer — Gergely Orosz. You Need to Start a 'whizbang' Project Immediately — Jeff Knupp. Work on What Matters — Will Larson. Notes on Distributed Systems for Young Bloods — Jeff Hodges. Choose Boring Technology — Dan McKinley.
As an aspiring software engineer, essays on programming have become a valuable source of information and inspiration.
They detail the thought processes of the best engineers in the world. They provide insight into how they formulate and articulate problems, communicate them to others, and go about solving them.
Humans are pattern-matching machines. To solve problems, we draw upon previous experiences to identify possible solutions. These essays — detailing specific problems and the solutions used to solve them — allow the reader to increase the number of patterns they’re able to call upon.
That’s not to suggest that reading can replace experience, but it can provide a valuable starting point.
These are the essays I constantly think about and call upon in conversation, and ones which I revisit on a frequent basis. If you’ve got any others that you think belong on this list — please, leave them in the comments — I’d love to read them.
It feels popular to bemoan slow software these days, and yet it also feels rare that a team is doing something about it — our tools still keep getting slower. My experiences lead me to the strong belief that while our tools do make it increasingly hard to write fast software, it’s very much still possible, and very much still worth it.
What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task. Users almost always have multiple strategies available to pursue a goal — including deciding to work on something else entirely — and they will choose to use faster tools more and more frequently. Fast tools don’t just allow users to accomplish tasks faster; they allow users to accomplish entirely new types of tasks, in entirely new ways.
As someone with a keen interest in product and consumers, this essay provided practical advice on what kind of skills to develop to become an engineer that plays a role in shaping world-class products.
Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. At companies building world-class products, product-minded engineers take teams to a new level of impact.
Every time I read this essay it makes me want to drop whatever it is I’m doing and get to work. It makes me excited for the possibilities that come with being a software engineer and determined to try and build great products.
The inspiration derived from each reading of this essay hasn’t faded over time — that’s what makes it a great essay.
_whizbang__ is a reminder to myself to try to tackle the really hard problems. I want to make software that seems like magic. Software that makes other developers stop and say, "Wow. I wonder how he did that?" Most software projects are created to solve rather pedestrian problems, and that's understandable. Programming languages, of course, are just tools. Most paintbrushes did not paint the Sistine Chapel. Most typewriters did not produce Moby Dick._
But at least one did, and that’s why the `whizbang_` directory exists on my computer (in fact, on all machines I control)._
In this article, see if there are any differences between software developers and software engineers. What you’re about to read mostly revolves around my personal thoughts, deductions, and offbeat imagination. If you have different sentiments, add them in the comment section, and let’s dispute! So, today’s topic…
Software development is something that is gaining popularity at lightning speed with the development of technology. The demand for regular developers is high compared to most other mainstream professions. But, what are the other reasons for learning to code?
There is no better moment for me than starting a brand new project. Everyone is afraid of adding or removing stuff. I guess we all have known at least one project that anyone wants to touch, or heard the phrase:.
To summarise the main differences between the software developer and engineer: A developer executes. ... So the software developer is mainly focused on developing code that is a part of software development cycle. An engineer designs and plans applying the principles of engineering to software development.
I remember my first fumble with basic on my ZX Spectrum computer back in the 1980s, ploughing through pages of basic commands and example code without any real idea of how I could write programs myself