Imagine you have a colleague named Boris. And Boris has a problem: he's been working on a new feature for five days, but now it's all falling apart. The application starts up, runs for a few minutes, and then shuts down with some weird error message and a huge stack
A list of tips to help you keep meetings on track.
Jackson is a go-to person when it comes to MongoDB. You have a problem – you go to Jackson.
Personal SLAs: How to maintain balance at work (recording)
Some people are lucky to work with extremely smart bosses. Molly hit the jackpot.
Functions inside other functions... Worth it?
Facing pushback while driving engineering initiatives: most common reasons, how to prevent and handle.
Meet Jeremy: he doesn't like old-fashioned tech interviews, but what alternative does he choose?
How a simple trick with console.log can help you with refactoring
The Boy Scout rule (always leave the code in a better state than when you found it) is famous among developers, but does it have its pitfalls? Meet Simon and Andy, who have a lot to share.
Why all new developers should do code reviews, how to begin and get the most out of it
Does your project have an enormous module called something-manager or something-controller that grew beyond any possible limits and became completely unmaintainable? How to prevent it from happening?
Highly effective colleagues are invaluable for keeping oneself sharp. But what if it works the other way around and makes you lose heart?
Types of people we may unknowingly use as pacers to adjust own behaviour. If you know them, you can control this effect and even change how you affect others.
Introducing the concept of pacers – people who can impact the performance of teams and companies by just speeding up or slowing down.
Although I'm not a big fan of reviewing code together with the person who wrote it, this approach has some benefits. Most importantly, it significantly shortens feedback loops which sometimes can last for hours and even days: This would be very easy to avoid if both the author and reviewer
How urgent is it to fix bugs? The question may sound ridiculous, but the answer isn't straightforward. Well, it depends on a bug, isn't it?
Do you have side projects? If not, you probably should think about it – they can be helpful in the long term. But I'd suggest being mindful when you're starting one – otherwise, it can cause unpleasant and unnecessary headache, as it did for me many times. But how can we avoid
Is it okay to use implementation details in tests? And if not, why so?
"Yesterday's Weather" is a popular Agile technique that allows teams to predict future performance. If you estimate, you definitely should use it.
No, it doesn't. You should never use it.
The data-layer of your application (database, Redux state, etc.) should not have any assumptions about the interface. When it does, it increases the risk of accidental complexity.
Tasks that can be difficult to estimate – how to identify and deal with them.
I'm going to publish the list of notes about software estimation. This is the first one.
The second part about Personal SLA
How to find a sustainable balance at work and how to make sure that people around don’t build unrealistic expectations.
I've been tracking time for 4 years. Any benefits so far?
A while ago I found a very inspiring article with 33 rules for artists [https://www.vulture.com/2018/11/jerry-saltz-how-to-be-an-artist.html] that actually is good not only for artists. If your work is related to creativity (even barely), you may find a lot of useful stuff here. The top
Run out of topics for bike-shedding? AHA Programming, Technical Debt and 17 ways to prioritise features.
Agile metrics, good error messages and a great long-read about rewriting applications
About good and bad bosses + why engineers are engineers. No crocodiles today.
TL;DR for those who don't want to read the whole note: > If people think about you as a leader, you should be extra careful about what you say in public, regardless of whether you meant it or not, because: 1. Leaders' words, by definition, have a big impact on
Tips for tech talks, a training program for senior engineers, a podcast about design for developers + one more way to categorise applications