Processes

I’m fascinated by how engineers read and interpret code that they work on a daily basis. It’s no doubt different for everyone, but few explain how they go about and understand a unfamiliar codebase. For me, being comfortable in a codebase usually means two things: Being able to jump to relevant, related parts of the code. Understand the implications of changing a piece of code Inside the system – impact of code quality. How does the code influence code in the same project? Outside the system – implications for human and program collaborators. How does the code influence other projects, teams, or users? Both can be addressed by following the data flow of the code. I refer to my strategy as assertions and assumptions. Take this arbitrary code snippet from Django: ...

When evaluating companies, its utmostly important to learn about the engineering culture. Culture for a company is simular to scope for code – culture provides a context for getting work done. Companies advertise their culture, but note that each company has a different culture. There’s plenty of articles about culture, so I won’t bother covering that. Just remember they aren’t necessarily the same. Companies tend not to be explicit about making sure their process matches what you expect. Be suspicious for a company that can’t explain it’s culture because that just means they’re not activitely trying to cultivate one. And that means it’s implicitly defined by the leaders of the company. Even if they choose not to define it. ...

Instead of sounding prescriptive, this article is much more descriptive. I’m describing my regular workflows: what is working; what isn’t working. I’m documenting this for completely selfish reasons since it’s useful to track progression (if any). It happens to be a great inflection point since a recent illness has thrown me off my routine in the past week. Like most people, there’s a need to regularly do: Respond to messages (twitter, facebook, texts) Respond to mail (physical, email) Attend events (birthdays, social gatherings, meetups) Capture ideas (they tend to come up in the most random places) Living (rent, bills, taxes, laundry, cleaning) All while (attempting) to achieve other goals: ...

There’s a process behind every result. If you say, “we have no process, there’s no meetings”, then that’s your process. Admitting to no process simply indicates that you don’t have it formalized. A poorly defined process hurts. Processes enable efficiency and consistency. They can also act like a communication protocol among team members, teams, and organizations. Process can improve your quality. Let’s think about how you deploy an application. What does that process look like? A poorly defined deployment process is inconsistent – something undesirable for a deployment. At minimum, a quick checklist works: ...

As an engineer, one of the most valuable skills you can have is to communicate effectively. This applies both to your follow engineers as well as non-engineers (PMs, designers, business). Obviously, this advice is generally applicable, but many engineers don’t craft their communication to the business well. Common problems are: Talking too much about technical implementation. Talking too little about technical implementation. Too much technical implementation drowns out the important details that businesses are concerned about. It drags on discussions and meetings unnecessarily. Imagine if a designer talked for hours about how they picked the correct border radius value and color for their buttons in a meeting. That’s a waste of time for business stakeholders and engineers in that meeting. Getting far into the weeds like that quickly wastes discussions or meetings1. ...