The Engineering Ladder
How I’ve come to understand the somewhat standard tech company engineering ladder
Recent content on Creating.Software
How I’ve come to understand the somewhat standard tech company engineering ladder
“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…
[ 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…
This post is a copy of a Facebook post by programmer Kent Beck . I still refer back to it and have found the advice about slicing up work to be particularly helpful (and I now pass it on to others). Kent Beck From years of watching master programmers, I have observed certain common patterns in their workflows. From years of coaching skilled journeyman programmers, I have observed the absence of…
What I learned about feedback as a junior engineer
Hi! I’m a software engineer living in the San Francisco Bay Area. I write about the ideas I’ve encountered that have helped me the most in my career, or (when I’ve dispensed them as advice) seem to have helped others. I hope some of them help you. I’m currently an engineer at SentiLink . Previously, I was the fourth (or third, depending on how you count) engineer at…
The epistemological structure of a piece of software and a scientific theory is the same: you can’t “prove” a theory is correct in the same way you can’t “prove” a piece of software has no bugs, but you can do lots and lots of testing The logical parallel clarifies (IMO in an interesting way) a fact of scientific research that I didn’t understand for a…
Incrementality is a style of development that affects everything in a software company, from “how to structure PRs” at the bottom to “how to release and market products” at the top. I have a collection of practices that I’ve learned, where general theme is to make software development more incremental. I use them unless I have a good reason not to. I’ve seen…
Software people love to debate the value of software timelines/project deadlines 1 2 3 . I think this hand-wringing arises from an incomplete understanding of how deadlines get missed. Deadlines are really a problem when software projects are harder than you thought they’d be. Emphasis on “than you thought” rather than on “harder”. Not knowing how hard a technical…
In Progress Teamwork Time Management To Do Add profile picture to “about” page Post “Decisions” somewhere - HN I guess Add comments to the Kent Breck facebook post Turn the “references” section into a single-page list of links, with comments explaining what you like about each Singapore essay on the model Went into “teamwork” “No Silver…