Andrey Agibalov There’s a magic word in software development: deadline. Say it out loud, and everything changes. Suddenly, things that were unthinkable yesterday become perfectly reasonable today. Code that doesn’t compile? Commit it anyway — we have a deadline. Tests failing? No problem, we’ll fix them later. Pull requests? Who needs them — just push straight to develop. And if we’re honest, after that kind of push, some people probably don’t even wash their hands after the restroom.
The moment a deadline appears, all sense of craft goes out the window. People start acting like the laws of physics don’t apply. But being a good developer isn’t about heroically surviving deadlines — it’s about not letting them sneak up on you in the first place. You have to know what’s realistic, what isn’t, and when “just one more feature” will cross the line from progress into chaos.
And then there’s the self-made kind of deadline — the ones we call “demo” or “prototype.” They work exactly the same way: a convenient excuse to lower the bar. Suddenly, every shortcut becomes justified because “it’s not production.” Developers love to say they’re working fast — but what they really mean is they’re cutting corners. They don’t use existing libraries, they “build quick” solutions that already exist, and they call that “rapid prototyping.” I’ve seen people build XML by concatenating strings, or write their own template engines using string.replace. That’s not fast — it’s what happens when you haven’t built a proper toolkit. It’s not laziness of effort; it’s laziness of craft.
Learning your tools — libraries, frameworks, languages — is what actually makes you fast. Because XML generation and templating aren’t exotic problems. Every developer faces them. The only question is whether you solve them with skill or excuses.
Deadlines don’t make bad code. People do. Deadlines — real or self-made — just give them an excuse.