Minko Gechev

It’s important to set realistic goals and track your progress on a daily basis. This way you’ll have an accurate idea of where you are at and roughly how long would it take you to complete the rest of the work. Often developers get into the trap of the perfectionism. They start trying to get everything look perfect and by the time they’ve opened their first couple of pull requests they are half way through the deadline. This creates lots of stress for delivering the rest of the work, bringing a lot of anxiety.

A big difference when solving a coding problem in a programming language is using built-in features rather than re-implementing them from scratch. For example, strings in JavaScript have a repeat method that allows you to get a new string that’s the concatenation of n number of repetitions of the original string. If you’re interviewing and you use the repeat method rather than reimplementing it from scratch, it’ll make your solution more elegant and give the interviewer the confidence that you have working experience with the given language.

You can accelerate a lot in your career by learning from others! This could happen in many different ways: - Open source - that's what have worked for me the most. Opening a challenging codebase owned by engineers who inspire you can help you learn a ton! Advantage of open source is that you could be anywhere in the world and still review the code of some of the brightest engineers alive. - Watching videos or livestreams - I've learned a lot about different coding techniques or shortcuts that improve my productivity from watching coders on YouTube or Twitch - Mentorship from senior engineers - that's another unique hands-on experience which you should take advantage of every time when possible.

Periodic review and refactoring of the code ensures the quality of the codebase does not regress over time. I've worked with many engineers who have shared that when they keep adding code over time to their projects without ensuring high hygiene their project collapses due to exponentially growing complexity. Frequently reviewing old decisions and ensuring there are no shortcuts that degrade code quality helps a lot! A big fear from refactoring is that it could break already working code. To ensure that's not a problem, just make sure you have a solid test coverage that brings you confidence that the refactoring doesn't cause regressions.

It's common in a large organization to move across projects using the same technology. Imagine each individual project following a different set of coding practices and style guides. This will significantly increase the cognitive overhead of switching codebases and reduce productivity. To ensure you remove the overhead of manually keeping track individual code changes align with the best practices accepted across the organization make sure you setup automation. For example, setting up a linter and code formatter that runs as your precommit hook can remove lots of manual work. Once you do this, add CI checks to make sure that only compliant changes make it to the source repository.

Understanding time complexity is essential to ensure you've chosen the appropriate tool for the job. For example, iterating over an array to find a particular element will take linear time (known as Big-O of n or O(n)). In contrast, if you're using a set data structure, or a hash map, this operation will have a constant complexity. You'll be able to perform a direct look up without having to traverse the entire collection.