You need both learning and doing

Great developers spend much of their time writing code. It’s not only about how much they study, read, and keep up with the latest trends but how much time they dedicate to hone their craft. They constantly make things. Again and again.

Great developers spend much of their time reading to improve what they already know. It’s not only about writing code day in and day out, but about keeping up with what’s new to stay relevant. They continually augment their knowledge.

I’ve seen people that can’t make anything useful, but they are always on top of what’s new. I’ve seen people stuck in the past, but are excellent building things with what they know. They both have a place. They are both in the middle of the pack.

To be a great developer, you need as much learning as doing. Every day is another opportunity for you to aim higher.

Naming things

I've written before about code clarity, but I don't think I paid enough care to the importance of naming things.

For the most part, we are sloppy and tend to minimize doing things that don't seem to be worth in the short term; we have natural incompetence to comprehend the long term implications of our actions. This reflects throughout our lives, including when we write code.

You can see the reflection of this in multiple different ways, but the one that brings me here is while naming things (variables, classes, functions, etc.)

Some people make an extra effort in being brief and cut their typing as much as possible. Here is when you find "vlcty" instead of "velocity" or "prc" instead of "process." Other people have a knack for finding the most obscure names possible, that although verbose, mean nothing after five minutes of typing them.

Unfortunately, whatever time they think they are saving by not taking the necessary care today, they will pay back later in brain cycles deciphering their code.

Writing code should be like writing a novel. Sure, being concise is a useful attribute, but most important is being clear. I understand that moving fast is excellent, but it can't come at the expense of clarity.

When reading your code, the intent should be obvious. It is not enough that you know what the code is doing: things should be transparent enough to provide answers to even the most casual reader.

This is a hard trait to develop. This is something that separates good from great developers.

Product Stages

When working on a product, it is good to have an understanding of what each stage of completion means. For different teams, these concepts will vary, but this is the way I like to do it:

  • A development version is a messy thing. You shouldn't expect much from it, and you should be ready for the application to blow up at any time without notice. We never deploy an application at this stage.

  • A beta version is stable, and as far as developers are concerned, it's bug-free. Of course, at this stage, the product needs much more testing, but you should be able to use it without too many issues popping up. You should never deploy a beta version for an audience wider than your beta group (definitely not to your production customers!)

  • A stable version (or final version) is good to go on production, and there are no major known bugs. Ideally, there aren't any bugs, but depending on what you are building, this might not be a reasonable goal. You should feel proud of getting to this point.

You might have a different definition for each stage of your product, but what's important is that your whole team understand what's involved in reaching each one of them.

By the way, trying to keep bug-free versions of your product could be extremely hard, and I've had to relax that constrain before because of multiple factors (time and money being high on that list.) Nevertheless, I always try to squeeze that bug list down as much as I can; there's nothing like feeling proud about the work you do.

Standups

One of the biggest complaints about the Scrum's daily standup meeting is that, more often than not, they become "status" meetings.

Complain about this to any die-hard Scrum fan, and they will quickly tell you something along these lines:

You are doing it wrong. You need to make sure your team is using this time to optimize collaboration and performance, improve communication, identify impediments, and improve the team's level of knowledge on the product.

The lecture will serve you well for a while, but for the last ten years, our standup meetings have degraded to status meetings shortly after. All. The. Time. Every. Time.

I work with smart people, and over the years, we've had a dozen or so specialists whose only job have been making sure our Scrum process is top-notch. We are proud of what we've accomplished, but the standup meeting seems to always be the same boring, useless crap.

Here is a crazy idea: maybe the problem is not our people, and we aren't doing it wrong. Aren't ten years, dozen of teams, and hundreds of projects enough to prove that the standard by-the-book Scrum standup meeting is not going to work for us?

I feel we have given them a fair chance.

Slow and steady

We made a lot of progress in our product over the last two weeks. It was a bunch of work, and it took nights and part of the weekend to get where we are right now.

I love the progress, but I hate what we had to do to get there.

The speed we showed is not sustainable. We can clap all we want but after a couple more weeks working like this everyone will be burned out and unwilling to move. This is not a great way to build a product. We are supposed to be running a marathon, not a sprint.

(Funny that Scrum uses the term “sprint” to refer to each iteration. I get why, but I don’t like the implication of speed wrapped in that term.)

We are scaling back the effort a little bit. Not sandbagging, but trying to be a little bit more realistic about what we can do with 80 hours of work.

I’d instead do slow and steady. We are playing the long game here, and my job is to make sure we get there as keen and excited as we started.

The stale backlog

Backlogs become stale quick.

As soon as some of the stuff reported in the backlog stops being relevant, the whole thing becomes useless and distracting.

I just removed 27 irrelevant entries from the backlog of a project I'm working on. There were 27 things reported in there.

I bet you a lunch that if you go to your backlog right now, you'll also find tons of stuff that doesn't make sense anymore. The amount of cycles your team spends every week sifting through stale requests is wasteful and completely unnecessary.

This is why I like to get rid of backlogs. Completely.

Instead, I keep a high-level plan for the next 4 - 6 weeks. If a feature or idea is not ready to be scheduled for that timeline, I ignore it. Important things will find a way to surface again and again, and as soon as there's enough clarity around it and we are ready to tackle it, I'll add it to the schedule.

This helps my team stay focused on what's important. It keeps them away from having to fish what's relevant from an ocean of dead requests.

The fear is always the same: you think you'll forget what's essential, therefore you need to add it to a list somewhere. I've found that this is the least of your problems when developing software. Forgetting is a good thing: it means that you didn't spend time doing something that wasn't important enough.

There will always be tomorrow

I understand some people have a different way to get to the finish line. Mine has evolved. I'm still a work in progress, but it's evident where I stand nowadays: I care first and foremost about putting something —anything— out there, perfection be damned.

I always struggled with convincing stakeholders about progress. More often than not I had to dance around the whole "...but the framework is already in place" idea. I liked to work from inside out; let's make sure we nail the "how," then we worry about the "what."

Not only this makes for a cumbersome conversation with people wanting to see the thing, but it also leads to waste as soon as it evolves.

More and more I try to focus on the product that people see. This is always my trade-off, the way I set my priorities. I focus on the stuff that fuels discussions, and drive ideas. I want products to evolve quickly, and I want as little waste as possible during that process.

There will always be tomorrow, and two hundred oportunities to make the "right thing." Just make sure you win yourself a ticket to fight that battle.

Don't get out of the way

A common saying that goes around is that a good leader "gets out of the way and let their teams do what they do best." I like it. I've also said it before.

There are good intentions packed inside those words. The whole idea is a direct shot at micromanagement and those who continuously become a roadblock putting their unnecessary self in the middle of everyone else.

I get all of that, but I also feel the idea is incomplete and somewhat misleading.

Good leaders don't get out of the way; they get right in front of the action. Good leaders don't disappear; they lead. No matter how good is your team, if they are craving for something, it's probably for your leadership.

There's a difference between leading and telling people how to do things, giving too little room for creativity, or overshadowing everyone all the time. The best thing you can do is not to "get out of the way," but to figure out how exactly you can help progress.

Don't make yourself invisible. Au contraire, you are supposed to be the always-shinning light making the path forward clear for everyone.

Commenting my code

A long time ago I wrote about how I felt about comments in my source code. It was back in 2010, but I'm not going to link back to those posts because I wrote them in Spanish. If you are sufficiently motivated, feel free to search the archives.

The story is that, back in the day, I wasn't very fond of comments. I had this personal quest where I had to refactor my code until every single comment was unnecessary. I still think is a noble mission, but the years have made me realize how hard it is to accomplish.

Add a few years of C development to the mix—where things are as hard to read as ancient hieroglyphs—, and my code has evolved to a completely different stage: nowadays half of my writing is not for computers to compile, but for humans to read and understand.

Time and experience do wonders to people.

There's something that hasn't changed, however: I never write comments about the what, but only about the why.

The what my code is doing should be obvious for any other developers — at least, I try hard. Sure, there are cryptic lines here and there, but most of the time, the code should be enough to the reader. The why however, is a different story: more often than not I try to go out of my way to make sure my intentions are clear through comments in the code, and every time I go back and read what I wrote, the ideas I had become apparent and I feel I'm right there the same day I came up with them.

I'm pretty much addicted to this, so I really think this is the last stage of the evolution regarding comments. I'll get better at writing them, for sure, but I don't think I can go back to noble missions that are hard to accomplish.

Finished

I always wanted to go to a US college, so back in 2015, I started my Masters in Computer Science at Georgia Tech, and just this month of May 2019, after a lot of work and effort from my entire family, I graduated with a major in Machine Learning.

Incredible experience. A lot of sacrifice for sure, but in my opinion, absolutely worth it — not because of the doors that this could open in the future, but because of all of the knowledge that you get.

I'm happy that it's over, but I would do it all over again if I had to.

The question now is, what's next?