So I finally managed to get a ticket to New York Tech Meetup. The day after I got the ticket I found out that I would be travelling on business on Tuesday and would not be able to attend. Bummer.
These tickets are notoriously scarce and highly sought after. Within several minutes of the tickets being released, they are gobbled up by some 700+ lucky attendees at $10 a pop. The unlucky rest ends up trolling the meetup message board where they have to resort to all sort of unsavory shenanigans to score a ticket — mostly groveling, begging, offering to pay above value, and then groveling and begging some more.
I didn’t feel like selling my ticket to a random stranger. Instead I decided to turn it into a social experiment of sorts. I wanted to see what people were willing to do for a chance to win this ticket, so what I did was to offer to give the ticket away to one of the next 10 people who would follow me on Twitter. It’s a simple idea, really.
Lately I’ve been doing a lot of thinking about proficiency and skill. Where does proficiency come from? How can we quantify and measure it? How is it different from skills that non-practitioners have?
So here are some of my thoughts. You are fully entitled to vehemently disagree.
I don’t care how brilliant a developer you are, every piece of code you will ever write will add to technical debt. Yes it will, and it will irritate you to no end.
Technical debt is one topic that instantly sparks debate and ignites controversy. I see the talk of technical debt crop up at work (even though we are still in the earliest stages of the project and haven’t accumulated much), and I see the need to manage technical debt in the code I write myself (even if my projects relatively small in size).
I believe what makes technical debt a development pain point is the fact that there are literally endless ways to continue to improve, optimize, refactor, enhance and generally better the code. Since most capable developers are perfectionists, these opportunities for improvement are a persistent and nagging temptation. It’s an issue that can affect productivity, team morale, and that has direct implications for the business value you are trying to extract from your team’s work.
Given the importance of the topic, I thought I’d share my own perspective and experience managing technical debt in a constructive and healthy way that still makes business sense. If you are lazy, you can skip to the “definite DO’s” at the end of this article.