I started blogging in the 90s as a way for my friends and family to stay informed about me. After doing it for a year, I looked at my stats and realized that I don’t have any friends and my family doesn’t care what I’m doing. Ouch. That hurt pretty bad and I was a little mad about it for a week.
I had an epiphany one day, while working with some bleeding-edge technology. I was finding most of my answers in people’s blogs. These were informal technical forums for people to share information to the development community. You could whip up a quick description that made the problem and solution clear, without having to be a journalist, etc. Bingo. That is what I should be doing. So I dumped all of my worthless personal material and started posting technical content, strictly.
Finally, some interest
Over the next dozen years (2001-2013), at work and at home, I came across several bugs/errors/snares that had no answers on google (or anywhere else). Let me tell you something: there is a really awful, sinking feeling that washes over you when you face a bug that nobody has solved yet. It is worse than a dream where you are at a party and realize you are naked. It is probably ten times worse than that. Each time that I found myself in this waking-nightmare, I hunkered down for several days (or weeks sometimes) and solved it myself. Oh, the blood, sweat and tears my-friend. Afterwards, I wrote-up a blog-post describing my methods and the solutions. Twice in my life, I have even googled an error message and landed on my own blog! Thank you! That felt awesome. Clearly, this was useful to somebody, even if it was only me.
Since then, my technical solutions have been much more popular than my personal life. For a long time, I expected this blog to improve my street-cred too, but I haven’t gotten one single pay-raise or job offer as a result of this blog. No biggie. I am still pretty satisfied, solely, with the good feeling of helping other programmers. I know that other people’s blogs have helped me, for sure. I’m glad I can give-back or pay it forward.
Looking back on some of my blog posts, I realize that I got a little silly or punchy in some of my stories. I want each of my articles to be informative and entertaining, so people don’t fall asleep before the end. I understand that any employer (or potential employer) who studies-up on me might get the mistaken impression that I am a goof-ball or jokester. Hopefully, they will recognize the technical depth behind these stories and not judge a book by its cover. [cliff notes on me: I’m serious at work, but I blog on “my time”, so I’d like to have some fun with it.]
The question behind the question
In the past two years, my blog posts have taken a bit of a turn. Instead of being all technical, I have been writing about methodology, programmer psychology, professionalism and philosophy (as it applies to IT). The reason for the big change is because, as I tally the value of the bugs that I’ve fixed, they really seem small compared to the monumental challenges that I have faced from a business/method perspective. As a programmer, I always win vs. technology. There is no compromise or second-best. There is only dogged determination, relentless pursuit and the sweet taste of victory. However, the projects that I’ve been-on, have been another story. I wish it was a long list of wins but it isn’t.
Now granted, it is hard to compare [me vs. a program] to [me vs. a large project] when I am programming, I am in command and it is me vs. the technology, mano-a-mano. I have the upper hand and I simply need to get control of the unknowns. It is pretty cut-and-dried. I’m in charge of a battle, not the war.
In a project, my power has limits: I only possess the power that has been granted to me. I can do the best job possible, but it stands to reason, that if I’m not in charge of the project, my success can still result in a failure of a project. Even if I advise the people in charge, they may choose to listen or they may choose to learn from their own mistakes. In which case, I have the choice to learn as well, or run away from the problem before I get caught up in it. By the fact that I am blogging about it, you could probably guess that I don’t like to run away.
So to me, those bad projects are great-big unsolved puzzles. It is my nature to want to solve those puzzles and to dig and dig until I find a solution. I find myself going over them and over and over. Although there is nothing that I can do to go back and resolve them, I can use that knowledge in my career, moving forward. If I ever face one of these again, I will not be blind-sided. I’ll have a plan/strategy. So, I study these messes in an effort to learn some big lessons from them. As a result, the projects that I have been in charge-of, have worked very well. Learning from the mistakes of others, has been a key factor in many of my successful projects.
This, not that
So, that is why I have all of these blog posts about technology and about methodology. My intention is not to gossip about anyone or any company. It is to learn and to inform. People learn more from mistakes than from successes. I just want to contribute to the programming community about a topic that seems to need a lot of help. Maybe you might be suffering from a bug in your process and you are looking for a solution. I hope I have given you some advice that can help you. If not, then it would be great if you could solve the problem and write a blog post about it. Then I can read your advice and be spared that pain. I’d love to learn from you, second-hand instead of first-hand. Thanks in advance.