Improve at work with (almost) every ticket

You’re at work and you’ve been assigned a ticket to make a table view with cells of varying heights. During estimation, the team decided that this was worth only a few points or only a few hours and they’re more than likely right. This is not a complex task.

However, you’re still not an expert. Of course you’re familiar with table views, but you don’t exactly remember how to have your cell heights adapt to your content’s size. That’s totally fine. Off to Google you go where you likely search for something like “tableview dynamic cell height”.


After a few minutes of browsing answers you end up finding a novel-like, 1700-word-long Stack Overflow answer. It’s certainly a great explanation, but right now you just want to make a cell change their height according to its content. Again, this is not a complex task. Luckily, if you keep searching, you’ll find a short and sweet answer. That one also links to an explanation, but you figure it’s only a few lines, so let’s just try it out and see if it works.

Incorporate it into your project

You code it into your project, test it out on your device and simulator and it appears to be working. Your body releases those sweet, sweet endorphins when you realize that you’ve just finished another task. If you’re at work, you’re ready to move that Jira (or Trello, or whatever) ticket over to the next column, clean up the code and submit a pull request.

Another ticket, another dollar 😏

Everyone does this

This flow works and it works well. If you found a well-written tutorial or a vetted Stack Overflow answer like the one I linked above, they likely explained the right way of doing things, so your code will most likely pass code review. Really, it’s not even shameful to prefer the short answer over the extremely detailed explanation in Stack Overflow.

You also did not blindly copy the code. You made sure nothing broke and made sure it worked on all devices. There’s nothing wrong with this flow… most of the time.

But delivering code isn’t improving

The scenario I described above happened to me many times and I’ve also seen it happen many times: a junior-mid level developer gets assigned a story that’s slightly outside their confort zone so they go and find a tutorial or a Stack Overflow answer. They apply the tutorial, make decent code out of it and they’re done.

Let me tell you the ugly truth: You’re stuck in a loop and your endorphins are rewarding you for solving problems right now. Your team will be very happy that you delivered good code, but your company’s needs don’t always align with what you need. Getting stuck in this search-implement-test-deliver loop is detrimental to your career.

Understanding code is improving

It doesn’t matter how well the tutorial is written or if it uses best practices or comes from an eminent developer. What matters is that you understand why the code they’re laying out in front of you works. You need to understand the solution in a holistic manner: why are these steps working?

You should absolutely continue using this flow to deliver good code. It’s the reason you’re getting paid, but you also need to go back to that Stack Overflow answer that explains in great detail what is going on and you need to understand it. You don’t need to memorize it in any way, but you do need to understand it.

The bad news is that there are all sorts of companies out there and odds are that your company is not very interested in giving you time to improve. Yes, they may have a budget to spend on books, and they may care about best practices but you’re not going to be improving on company time – you’re going to be delivering software on company time.

In the end, it doesn’t matter if you’re improving while on the clock or on your own free time. Don’t go through the motions and think you’re improving. Improving is a conscious and concerted effort.

Action Items

Once a month, I’ll share a post with an action item. The item will be something you can do right now to improve.

  • Write down a list of 3-5 issues you’ve worked on during the past two weeks. How much of that code helped you improve and how much was just code that needed to be delivered?

If no items helped you improve, you may need to ask your boss for some training time (my email is, I can help crafting that Slack message or you may need to use your own time.

If you liked the item above, I share out weekly action items on my mailing list. Feel free to join!