During one of my first jobs working in software, I was responsible for working on the functionality that allowed the front-end to talk to the middle-ware asynchronously.
That sounds way fancier than it really is, right?
Basically, I was doing a lot of Ajax. Of course, at the time, it was really cool stuff because it was while Ajax was become more mainstream, and the product on which I was working was using Prototype, and had a lot of neat stuff going on.
But whenever you end up using a new technology, and they are supported in a variety of ways in different browsers, then you’re bound to have edge cases that your users catch that are not caught by you or your testing department.
And if you deeply care about the stuff on which you’re working, getting support tickets for the things on which you’ve worked can sometimes be a major downer.
Then, when I began working at my next job, I noticed the same things happening: We were building cool stuff used by a lot of people, we had unit tests, front end tests, and even a dedicated front end team, a long with continuous integration software with deployments to staging.
It’s a textbook example of everything a good software shop should be doing, right?
But it doesn’t talk long to discover that the same problems seem to exist in those environments, either.
Taking It Personally
Since I’ve moved to self-employment, I’ve had to focus on things that are normally able to be handled by a team, or at least reviewed by someone else. Don’t misunderstand: I recognize this is responsibility that comes with the territory, and if something goes wrong, I have no one to blame but myself.
But never before have I been so ingrained in each aspect of development for each project as I am right now – partially because I’m making a living on exactly that, and partially because I’m more personally invested in my work than I’ve ever been.
For the most part, it’s a great place to be. I’ve never been happier.
The thing is, despite the fact that I’ve been working in the industry long enough to know what constitutes things that we ought to do, things we ought not to do, and things that are considered to be best practices, and despite the fact that I supposedly have more riding on my work than ever before, I still take issues personally.
No matter how detailed I think I am, no matter how feature complete I think I’ve made a feature, there are times where I miss things, and the feeling that comes with having to accept that mistake is just as great (if not greater) than it was years ago.
Everything is Important (Not Everything is Urgent)
This is arguably one of the largest personal challenges that I’ve dealt with my entire career: When a bug arises, or an issue is raised regarding a project, feature, or even a small aspect of something I’ve worked on, I take it personally.
By taking it personally, I don’t mean that I’m offended (I’d argue that’s on par with being arrogant, but I digress), but that I feel personally invested in the fact that I’ve disappointed the client, clients, or people on the other end with the fact that something I did failed to solve their problem as planned.
Usually, it doesn’t matter if it’s as something as small as the way something is presented, or something as big as how performant a query is – it’s the principle of the matter.
If you’re someone who’s been involved in the industry for a while, then this is something you learned some time ago, and if you’re someone who’s just getting into the industry, then perhaps this is something that can help you bypass some of the learning process.
When it comes to building software for others and dealing with the inevitable problems that come after the release, everything is important, but not everything is urgent.
Sure, some may disagree, and this is not to say there aren’t urgent matters (because there clearly are), but for whatever reason, there are things that are treated with a sense of urgency that are not preventing anything from working, that are not hindering the user or the customer from getting something done, or that are not stopping the overall product from working.
Perhaps that’s too general of a grid through which to define urgency, but it’s a term that’s respective to the project at hand and I can’t possibly cover that all here.
But the greater point remains: When things go wrong, good developers will be invested in their work, and will treat problems as significantly important issues.
This means…
- The problems are deserving of our attention,
- We should aim to understand what went wrong,
- We should diagnose, fix, and be able to explain the problem,
- And we should have a plan for how to make sure this doesn’t happen again in the future.
Good developers will not easily de-prioritize issues that have arisen in a project that they’ve worked on after it’s launched. This doesn’t mean that I suggest yanking it to the top of your task list, but that it should not be easily dismissed.
Does It Ever Go Away?
Of course, I’m writing this as much to myself as I am to anyone else who is reading this. I don’t necessarily know if this sense of personal investment and emotional tie-in to your projects ever really goes away (any older developers care to chime in?).
I know that just as I get disappointed when things don’t go as expected, I also share in the excitement of launching a project for someone, and smiling along as the project does what it’s supposed to do for whomever it is supposed to serve.
Whatever the case may be, it took me longer than I would’ve liked to learn to understand that things are important, but rarely urgent, and I hope this benefits whoever else reads this as they’re going along their journey into project and product development, as well.
Leave a Reply
You must be logged in to post a comment.