One key trick to becoming a wizard developer
Why dig into problems that you could work around? Three reasons: one about my work, one about the team, and one about me.
Why dig into problems that you could work around? Three reasons: one about my work, one about the team, and one about me.
Batching work is more efficient … until cost rises nonlinearly with batch size. Then smaller batches are the most efficient. So don’t delay maintenance!
The most productive developer on a team is usually the one with the most knowledge of the system. Of the code, the business domain, the other software this code interacts with, and the people in the organization who can help. How did they get that knowledge? By working on the system. Weinberg remarks that when …
One way to be a 10x developer is to write the system, so you know more about it that anyone else. I call this person the “purple developer.”
TL;DR: When you want to build one platform for all your lines of businesses: stop. Don’t. Build systems for each instead. Keep the integrated parts as small as possible. This minimizes costs, while enabling change. A global, unified platform to support all our lines of business! Doesn’t that sound glorious? CIOs puff out their chests. …
Read moreNonlinear increases in complexity make unification excruciating.
Y’know how sometimes a particular logged-in user isn’t authorized for some option, so you don’t show it to them? Don’t do that to people. Tell me it’s there, tell me I can’t do it, tell me who can. This is what happens when you hide it: Dave and I exist in different worlds, and we …
I wanted it to be turtles all the way down. (where turtles are objects, or functions)
But it isn’t…
Giving birth and nourishing,making without possessing,expecting nothing in return.To grow, yet not to control:This is the mysterious virtue. Lau Tzu, Tao Te Ching Can we make software, and care for it in productionwithout feeling possessive of our code? The software gives us nothing back. It could emit events for us. If we listen to its …
As developers, we build systems. Right? We build software that stays up (in aggregate) and performs functions. Sure, sure. Is that system useful by itself? I say never. When your team builds a service that adds a capability to the business, and it’s called by other internal software, then that other software is essential for …
“Teams use CheckMarx to make their code more secure.” CheckMarx is a tool that analyzes code, looking for vulnerabilities. It produces a report of likely problems, with specific locations in the source code. “We will mandate that our teams use CheckMarx.” Will this make the code more secure? That depends how the team reacts to …