I recently had a company dinner with our principal architect at one of our company all-hands meetings. It was one of the first times we had really sat down and talked, not just about work but about life and hobbies or whatever.

Spoiler alert: It was at a sports bar.

It should be noted that earlier that day, we had a Go-No Go meeting at work about our first public release at Storj. As anyone that knows me personally will attest, I’m not shy about voicing my opinion. I’d been very pro-release that day, but we had decided to hold off for a week before releasing.

This naturally came up during our dinner, and we started talking about the finer points of that discussion. Eventually, my change of heart got brought up (I’ll get to this later on) and we started talking about why I had changed my mind. This led to my coworkers discussing their own approaches to that conversation, and their own concerns with the release, as well as their concerns with mine and other’s opinions.

It may have been that I was a little bit buzzed, or it might just be my general lack of shame, but either way at one point I blurted out to them “So tell me how to stop sucking then, man!” I was half joking, but they took it in stride and began to immediately lay out some of the things I should improve on. This ended up being one of the most valuable conversations about my career that I would have.

They pointed out a few things I could work on, and a few things I had never even considered.

Get this: they were 100% right.

There’s always room for improvement.

Incremental improvement is the name of the game when it comes to programming. This year, I’ve definitely been challenged more than any previous year that I worked in software. It rivaled my time at code bootcamp. That’s a good thing, though! I grew a lot because of it.

So here’s the advice that I was given at 11pm, a little drunk in a sports bar and completely invested in the conversation.

Read code backwards

Start at the return, and try to work your way backwards from there. This is easier in typed languages, but still possible in dynamic languages (Python or JS, for example.)

The idea behind this approach is that it might uncover a more elegant or simpler way to get to the finish line than you previously saw. Additionally, it will keep you focused on the “end goal” - which is what you’re returning out.

Another benefit is more subtle but it’s still there - you can find some more subtle bugs this way. For example, I was looking at a piece of JavaScript that had some listeners declared on it. When I read the code forwards, it made sense - they were cleaning up their listeners after the main body returned.

However, when I read the code in reverse, the bug stood out - the loop was preventing certain listeners from ever being destroyed, resulting in a memory leak. Now, I probably would have found that bug anyway, but reading in reverse made me think a bit more critically and I found it faster than I would have guessed normally.

That’s one obviously anecdotal piece of information, but I think it lends itself well to the explanation here - reading in reverse decouples your processing from the monotony of reading code, and forces you to focus harder on the single line of code in front of you.

Read code. Like, a lot of code

They suggested to me that I read, at minimum, 1000 lines of code per day, as just a starting point. More is better. This can be counted through code review, digging through documentation, or even just browsing libraries you’re interested in. However you achieve it, though, it’s important that you actually do it.

The hidden gem of reading code is that you learn new, more clever or cleaner ways of doing things you already know how to do.

The more obvious gem of reading code is that you learn how people build things you had no idea how to build. Want to get more familiar with databases? Go read the source code of PostgreSQL, or CockroachDB, or Badger, or whatever. Don’t feel like you fully understand what Mongoose does for you? Go read the source code. Make notes on it. Go read the code that powers populate() and know what true hell really is.

The more you read, the better grasp you’ll start to get on more abstract programming principles. Why is composition better than inheritance in this case? Why is this better as a callback than a promise interface? Ask yourself these types of questions while you’re reading the code, and then go figure out why.

Bonus points: Contribute to some open source! It looks great on resumes and you’ll learn a ton in the process.

The Infinite Possibilities approach

One of the more interesting approaches that I was told to try was coined the “Infinite Possibilities” approach.

It's a Unix system.

To try this out, they suggested taking a single code problem and writing it out as many different ways as you can think of to solve the problem. It helps if you have unit tests, but you can still practice this if you don’t.

Every time you come up with a new solution, you can get a better grasp of the pros and cons of each solution you’ve previously written. This is the real value of this approach - it forces you to try different routes, and every route will have different pros and cons.

I’ve taken this approach a few times in my own side projects, and it’s been really beneficial. Even more frequently though I find myself using this approach at work. One of the subtle benefits from writing out “infinite” approaches is that you can quickly answer why you didn’t do something a different way. If you already wrote the code to do it that way, then you can immediately answer why your way is better, or at least why you think your way is better.

10x your code reviews

something something GOOGLE

It might seem counter-intuitive, but one of their strongest suggestions was to set a minimum number of comments that you aim to leave on every single pull request or code review. I thought this was a very interesting approach, but after it was explained it made a lot of sense.

By setting a minimum number of comments to leave (say, 3 per code review) you are forcing yourself to find even tiny flaws in every pull request. This increases adherence to the company style guide, makes sure there are no spelling errors, catches unnecessary fmt.Printf or console.log statements, ensures that code has proper commenting, and might even catch some bugs. Hey, that’s pretty neat!

Admittedly, I was resistant to the severity of our code review process until this approach was pointed out to me, but in the long run I’ve adjusted to it and now even appreciate it, and I work hard to be equally as detail oriented when I work on other code reviews now. Code review is the last step before production, so it’s importance can’t be understated.

Assume that everyone else has information you don’t, then proceed from there

This is the least code related tip I was given this night, but it’s important and worth mentioning. Once you’ve assumed everyone else is more informed than you are, then start to model your questions. Remember the 5 W’s. Ask about everything that you don’t understand. Question why something isn’t being done. Question why something is being done. Be vocal, but don’t be proud.

You have to be ready to accept that you’re wrong, and that’s hard for some people. For me, personally, my first instinct is to claim the blame and absolutely wallow in self loathing, but that’s not the point. The point is to move past being wrong and move towards assisting in being correct.

During our Go-No Go meeting, I had the strong opinion that we should launch, citing the “You should be ashamed of your first release” mantra of “MVP” style releases, and insisting that I didn’t want to keep kicking the can down the road until our next release was looming and we were a full step behind.

Did I make some valid points? Yes. However, there was also important information I didn’t have. We had some glaring security issues that could have been exploited for money. In my defense, I was operating on the assumption that we weren’t funding anything until later on, but that’s exactly the problem: I assumed I knew everything, and once I learned that crucial piece of information, my entire opinion changed.

You ain't know shit.

The point is, you need to be aware of what you don’t know, which is probably a lot. Organizations are made up of single, atomic individuals who have their own opinions, perspectives, and knowledge silos. While it’s generally a good idea to work on reducing the amount of information that resides in these silos, it’s impossible to make that number zero. Proceed as if you know nothing, and ask questions until you get to your answer.

It may be that I was a little bit drunk.

Or maybe I was just very open minded that night.

Either way, that conversation was one of the best and most thought-provoking conversations I’ve ever had, and I encourage everyone to ask their boss straight to their face how they currently suck, and how they can stop sucking as bad.

Okay, maybe that’s not the exact quote you shoud use, but you get the idea.