Photo by Belinda Fewings on Unsplash

In February, I joined another team within the company. Our main objective is to make sure our ERP integration API is enterprise-ready when we start bringing on bigger customers.

I'm looking forward to digging deeper into that.

Although February wasn't eventful I didn't manage to read a lot, so, unfortunately, this will be a short list for now.

Tricks I learned to improve my communication

TLDR;

  1. Keep track of the conversation
  2. Delay your opinions
  3. Explain tech on the right level of complexity
  4. Make sure everyone is on the same page

The Wall of Technical Debt

TLDR;

The Wall of Technical Debt is a surface in your office where you visualize these issues on sticky notes. It’s easy to start and to maintain, and yet has a profound impact on how we choose to add, reduce, pay back, or ignore debt. It’s by no means intended as a complete solution to scale the management of debt. It works precisely because it requires no buy-in.

When Is the Perfect Time to Move on as a Developer?

TLDR;

As you know, some folks have 20 years of experience, but actually, just one year repeated 20 times. Let’s call it “the left side” of the scale.

And then there are outstanding professionals, who have only, what 7 years, but all of these years are unique experiences that make them exponentially better than the former. These are probably top performers in their field. Let’s call it “the right side” of the scale.

And then there is everything in between.

So how does one get closer to the right side?

  1. Don’t chase only “new and unique” all the time—make sure you actually get good at skills and responsibilities before you add more things to your repertoire.
  2. Challenge yourself every day. Be ready to answer the question “what did you learn yesterday” with something substantial. Perhaps add “how did you fail last week” to the list of these must-be-able-to-answer questions.

In fact, answer these questions every day, if you can help it.

Never become complacent and have an “easy job.”

  1. Get more skills that’ll help your team/product/company to become more successful when your current skillset starts to near the “easy job” state.
  2. Become responsible for more (and more important/challenging) things.
  3. Make sure that what you’re adding to your “toolbelt” is actually valuable to people around you, your product, your company, or your customers.
  4. If your path forward makes the above not true, then it’s time to switch a job. Don’t forget to negotiate a larger paycheck, as this is the easiest time to do that! Use this to find out what is the pay at the company you are negotiating with.
  5. Finally, if such a company doesn’t exist (or is inaccessible to you)—then create one! Become independent.

Your code should tell a story: Tips for writing code for others to read

TLDR;

  1. Use functions and variables to convey your intention, not comments
  2. Use variables to explain control statements
  3. Avoid ambiguous arguments
  4. Magic is good in some stories, not in ours
  5. Use enums. Avoid using strings as identifiers
  6. Favor verbosity over brevity

Thank you for reading, you're awesome!