“You can ship all your features, or you can ship on time, but you can’t do both” – God A Story Pachyderm Projects (I’ll call them “namespaces” for blog purposes): “all the functions in PPS identify repos with a string: the repo name. Well, with projects, we need two strings: the repo and the project. This is a major refactoring, affecting all of our functions and classes, as well as our database schema. ...
[ Decisions part 3 of 3 ] In this essay, I use the ideas from “Decisions” and “The Theory of a Program” to lay out what I’ve learned about how software teams work and how you can build your career.
[ Decisions part 2 of 3 ] The “theory” of a program: it is the intricate knowledge of why a particular solution was chosen over its alternatives that allows software to be good. This reality is the root of many challenges in software engineering.
[ Decisions part 1 of 3 ] “Decisions are something you make; something is created when you make a decision. Making a decision is an act of will, not an act of thought.” I’ve come to love the analogy between a decision and a tangible, creative work, and now see the need to make innumerable open-ended decisions as the defining characteristic of creative work.
The nature of being a Software Engineer: you wake up every morning, and you have a million things you need to do, all of which will kill your startup/get your project cancelled if not done: a hundred tests to fix, a thousand messes to refactor, ten thousand features to add. This week, you have time to do two of them. Unless you decide to really push it, starting early and staying late, charging boldly into the abyss; then you might be able to start on a third. ...
What I learned about feedback as a junior engineer