Maybe that I’m a graybeard programmer means I’ve finally realized my potential as a programmer.

I’m reading this list of “10 Reasons Why You’re Failing to Realize Your Potential as a Developer“, and I’m just nodding my head the whole time. I’m going to add my own comments to the author’s “10 reasons”, so you should read the original article first.

1.  You’re too afraid of failure to learn new tools / languages / frameworks.

I’m not sure it’s fear of failure as to why people don’t want to learn other stuff. It may be as simple as having a comfort zone and wanting to stay there. It may be that they have a cushy job and want to keep it (maybe fear of losing job). There may be business reasons.

He’s right tho, that people are afraid of throwing away all those years of investment in X. The reality is, you are and you aren’t. You may well throw out a specific set of languages or frameworks, but so what? After you’ve learned enough languages, another is “just another language”. After you’ve learned enough frameworks, it’s “just another framework”. A lot of the concepts and approaches carry over, and it’s those things that matter more. You have a larger set of experience to draw from to solve a problem, to create an architecture, to see a flaw or a risk before it becomes too costly. Those things are far more important than you silly language wars.

It’s good to learn more languages, to learn more frameworks. The more you know, the  more cool stuff you can do, and ultimately the more valuable you can be. That said, be sure to acquire depth in those areas. Having a list of languages a mile long doesn’t mean much if you can’t actually be useful in those languages can can’t speak to the depth of what they offer.

2. You won’t push your commits until the feature is “done.” (It’s never done!)

I think this is “fear of what others think” or “fear of judgment” or “fear of criticism”. That people won’t think you’re a god, or that you’re stupid for how you’ve done things. This is a reasonable fear. We’re human, we have egos. The geek and programmer are held up as some sort of wicked smart superman and the exception is taken to be the rule. It also doesn’t help that there’s often someone on the team that doesn’t know the meaning of the word “tact” or even “polite” when looking at someone else’s code. We basically always think the guy before us was a moron and can’t believe they wrote such stupid code!

Screw it.

You will write stupid code. You will write imperfect code. Your code will have bugs. You are human. You are learning. You will do the best you can at the time you can with what resources you have. I find this is where comments are useful because they can expose the hidden “why” behind something. Maybe you have to write an ugly hack, but at least the comment can explain why you had to do it (because we had to ship right now else lose a multi-million dollar contract and the company would have closed up and none of this would have mattered then). It may not excuse the choice of hack, but at least it becomes understandable.

Just commit, often and early. In the long run it will suit you better because you’ll need to roll back or have a good checkpoint, so your workflow is better served by doing that. And in the end it really doesn’t matter WHEN you commit your code, because we’re always going to think it’s wrong and wonder what moron wrote it.

3. You know just enough to be dangerous.

I’ll just say you need to read and understand, before you do.

Sometimes you have to “do” in order to fully understand. If so, take time on the side to write a small project that allows you to fully explore and come to understand it. Often tho, a little sample project isn’t enough and you just have to drop it into the larger more complex context to really grok it. But then this goes back to #2, where you should commit often and early, so we can follow what happened and unwind it when something bad happens.

4. Analysis paralysis.

This is a tough one, and one that only comes with time and experience. Plus, it’s different for each person.

You cannot sit there and analyze all day, but you must analyze and research some. If you don’t understand what you’re doing, then you only know enough to be dangerous and we come back to point #3. Or you risk going in half-baked and everything gets fucked worse than before.

But you also cannot sit there and just analyze it to death. Sometimes you just have to dive in. But then it goes back to #2. Commit often. Heck, make a branch, maybe a branch of that branch, whatever you have to do. Sometimes getting in there and poking at it is the only way.

There’s a balance to be had, and ultimately you just have to find it. Never lose sight of the fact you have to ship, because you need to make money, because you need to get paid and pay bills and such. So if nothing else, let that be a motivator to keep going, just don’t rush it.

5. You don’t invest in your tools or development process.

This is a pretty good one.

I’ll just add that scripting has been one of the things that has helped me. Eventually I’ll recognize a task that I perform often (enough) and takes (enough) time. I’ll also see the task is one that tends to be the same thing over and over, or maybe almost the same with just some small variation of input. That sounds like a perfect candidate for automation! So maybe it takes me a day or two to come up with a script or other mechanism to automate it. Fine. But now it’s a simple execution of the script and viola, the thing is done. Or the thing can churn in the background without my tending to it, and I can go tend to other things. In the end, I get more done in less time.

How does the saying go? “Efficiency is intelligent laziness.”

6. You’re too embarrassed to ask for help.

Don’t be. You don’t know it all.

On the same token, don’t be an asshole when someone comes to you for help. If someone comes to you for help, they are in need and believed you to be the best person to aid them. Help them, and don’t be a dick about it. And yes, that includes things like LMGTFY, or just saying “RTFM” or “did you use the search feature” or other shit like that. There are ways to help people become more self-sufficient, but being condescending isn’t one of them.

7. You don’t know how to make it easy for other programmers to work with your code.

Your code will outlive you. As well, once you have written code, it will have to be maintained… often by you, and chances are 6 months from now you won’t remember what the hell you were thinking when you wrote it.

Write clear code, clean code. Yes sometimes architectures have to be obtuse or complex. So document them. Explain them to others. Be sure to share the knowledge.

8. You don’t know how to read someone else’s code (or don’t want to.)

This goes back to #7, that you should make it easier for people to read your code. In fact, it goes back to #2, because you should be pushing your code to others and soliciting their feedback. Code review is good.

Granted, we shouldn’t get hung up on coding styles and coding standards, because someone’s will always be different from yours. So you need to learn how to read their “dialect” and forge ahead.

9. You can’t code from the end-user’s point of view (you think too small.)

This this this, so very much THIS.

We must always remember who we are coding this for. When I write a script (#5), I’m usually writing it for myself so if it’s quick and dirty, that’s fine. So long as I can make it go that’s all that matters. If it fails along the way, that’s OK because I can fix it. But if I was to make that same “automated task solution” work for someone else, I’d probably have to make it cleaner, clearer, I might have to put a GUI on it, make it more robust in the face of failure, etc..  It’s the same basic solution, but because of the audience the specifics and the end product are different.

We do not reside in an ivory tower. We must realize that we are generally not the audience and our take on things isn’t often the way it should be done. It was one then when I worked for Metrowerks, being a developer writing tools for developers, so often we could use our assumptions and biases and turn out the right features and approaches. But when I wrote Spring Cleaning and was writing an app to make life easier for non-tech-savvy people, that affected everything and directed how even things as simple as error messages must be written.

But also, don’t let this get you arrogant. I often hear that the customer doesn’t know what they want and so we must give it to them. Actually, customers often do understand what they want, but they have a hard time articulating what they want and may not know how to articulate it. But often they will know it when they see it. Thus it becomes OUR job not as a programmer but as a designer, as an architect, to learn how to draw this out of the end user. To step back, to see the larger trends, the directions, and the problems faced by our end users and then see how we can solve them to give them a solution that not only gives them what they want but in a way that’s better than they expected.

This isn’t easy, and it’s nothing a novice can do. But it’s a position for the novice to strive for.

10. You aren’t able to judge the business value of any programming task.

I will never forget Doug D.. Doug was a manager I had early on in my career. I was this idealistic programmer that enjoyed my ivory tower. I wanted to write perfect code, and do great things as a programmer.  Doug helped me realize that while that’s all good, there’s business to think about. It’s simple. Money has to be made. There has to be money to pay my salary, to keep the lights on, to pay my salary, to put Mountain Dew in the fridge, to pay my salary, to keep the business floating so we can keep our ivory tower alive and going to even bother with any of this code. If there’s no money, none of this stuff matters and our ivory tower of ideal programming goes away. So you have to look at the business side of things. You have to keep perspective. And sometimes yes, you have to not do something, you have to leave some task, adjust priorities, or even sometimes take a hack approach instead of a clean architecture. There’s just realities of business. Many times it may lead to ugly things that are more painful to recover from down the road, but that’s life… at least you stuck around long enough to have that longer road instead of having to pull up stakes miles and years back to find a new home.

Nothing will be perfect. We have to find balance and constantly juggle priorities.

Just don’t forget to grow and have fun along the way.