cdruc

Three minutes into a meeting discussing a new feature and we already have a list with tables, columns, flags, objects and methods in our head. It’s involuntary. Whenever we talk about a new feature we jump into programmer mode as soon as we get the chance. We need a model for this, a controller for that, and then we render this component and sync with that API.

Going into too much detail when discussing features makes us lose focus. Programming and figuring out how things should work are hard enough on their own. There’s no need to mix them together.

It’s not only harder for us to reason about the system we’re building. It also creates some kind of lock-in. It’s hard to reverse any of those decisions taken during the meeting. Even harder if you’ve already built something. Because “we discussed and decided that this is how we’re going to do things”.

We act like those initial thoughts are set in stone. Instead of going back to the drawing board and undo the things we’ve done, we build around them, making an even bigger mess.

Refrain from including implementation details whenever you’re trying to figure out how a new feature should work. Get your business rules spot on. Then figure out the implementation.

It’s hard to make things work. But it’s even harder to explain how you did it. Here are a few things you could do to help me, you, and others understand your code.

Good formatting. Yes, that space between operators is important. Line lengths, line breaks, blank lines, camelCase, snake_case — they all make a difference. Be consistent, adhere to a guide.

Careless naming. Don’t use abbr. Don’t make me guess. Don’t mislead. Be precise. What is it? What does it do? Why it exists?

Conditionals and switch statements produce different outcomes. Which means I have to read the code again, and again, and again…

Nested loops, nested loops with conditionals 😮 . Same as above, only a million times worse. Get rid of them.

Hide stuff I don’t need to know. I don’t need the details. I want to be able to say “ah, it does this” without knowing exactly how. Write in cascade. Start with high-level concepts and add more details as you go downstream.

Make smaller things. It increases the number of files, classes, and methods and makes it harder to reason about the whole system. But that’s the idea. I don’t want to reason about the whole system. I can’t. Nobody can. I’m more efficient reasoning about small things. One at a time.

Don’t fall into the “I’m the only one working on this” trap. There are at least two people working on a project during its lifetime. The first one is you. The second is the you after a few months.

Put some more care into your code. Name stuff a little better, split classes and methods into smaller ones, make it look and read well.

New project. We have our meetings, we come up with a plan, we somehow agree to a budget and then we get the ball rolling, coding our way to the finish line.

As we build stuff, fresh requirements are sent in. “We need this new feature”, “we haven’t thought of that”, “it would be nice if…”, etc. And it’s ok. We saw this coming.

Displaying that list on two columns, making those elements editable, changing that color, size, font, whatever — they seem to have such a low value that we often neglect them. But they pile up and sometimes affect the system in ways you wouldn’t expect, taking an even bigger dip in the budget.

We are bad estimators. But that’s not the worst part. The worst part is that we rarely, if ever, say no to a client.  One reason, apart from the customer is always right and make the client happy, is that it would make us feel incapable, unworthy of our profession. We take saying no as something to be embarrassed of. It’s not.

Saying no not only leaves you with fewer things to do but also leads to a major increase in productivity. It’s far easier to stay focused when you don’t have to worry about the “would be nice if”s.

The devil’s in the details. Control the scope.
Focus on what is essential to create value now. Add the rest later.