thoughts on coding and everything in between
Category Archives: Craftsmanship
Do you consider yourself a pretty good employee? Or have you attained “rockstar” status at work?
Or are you like those people on American Idol who have been told they totally can sing and would hands down win, but they actually really can’t sing to save their life?
All too often it seems I encounter people who think they are all that plus the six-plus figures they are expecting, but the truth is that they are not operating at that level of responsibility and excellence.
I have recently been through the process of interviewing candidates for a few positions and I am sorry to say I was very disappointed with my hiring choices. I was looking for quality employees who needed little guidance from me or anyone else. I was willing to pay for quality employees! I needed people who could pick things up quickly, be self-motivated, problem solve on their own, and for heaven’s sake could follow the simplest of directions. I thought that is what I was getting based on the interviews I conducted and the money I was putting on the table. Little did I know.
It seems the understanding of quality work and workers has been lost. People either cannot see the bar anymore for the great distance it is above their head, or they have taken the bar down and put it on the ground in the name of entitlement or sensitivity to others.
First off, good work is not the same as good enough work. If you care anything at all about what you do or what your work efforts produce, you should do more than just good enough. Think about what good enough says about you. With a bit of training, any person could do good enough. It certainly doesn’t say “I’m irreplaceable” or “I do valuable work”.
If you don’t care whether or not someone can say that about you at your current job, start looking now for one where you do care. You are hurting yourself, your employer, and your co-workers by churning out worthless work and wasting your (and their) time. If you can’t find another job right now, then look at the job you’re in as practice time and practice doing what you do really well so when the time comes, your new employer will be ecstatic to have you.
The point is, raise the bar. Do more than just enough. Make yourself valuable.
Perhaps those paragraphs don’t describe you at all. You are a hard worker and you know you do good work. Excellent! Now, let’s raise the bar.
Ask yourself where you could be better. Better yet, ask your co-workers and your boss to give you honest feedback of areas of improvement for you. Be prepared. You might not like what you hear. But I guarantee that if you actually work on those things, your perceived value will increase. And that perceived value will become real value and increased value as you work on those things.
So just to give a few concrete and practical ways to raise the bar, here are a few things to try:
1. Come up with solutions to problems instead of always just pointing out the problems. I’m not talking about emergencies, but for non-emergency types of problems, practice your critical thinking skills. Roll your sleeves up and see what you can do on your own! For heaven’s sake at least give it a stab on Google! Not only will people around you see that you are doing more than just enough, you will grow more than you probably thought. Win-win for everyone.
2. Practice. Even if all you do is squeeze in 30 minutes on your lunch break, its well worth it to practice your craft at least a couple of days a week. You will find your own shortcomings this way. Set the bar high and see where you fall, then practice improving until you surpass that fail point.
3. Practice integrity. Be honest with others and yourself. Be an ethical employee (come in on time, don’t leave early, etc). Don’t talk bad about others (especially not those you work with or for!). Upgrade your vocabulary at least in the office (sure it’s hard to keep it clean, but you will be seen in a far better light if you can control your tongue! Especially in front of customers!)
4. Learn. Don’t freak out, I’m not saying you need to go back to school (although, kudos to you if you decide you do need to do that). Take the time to learn a new skill at work or to improve upon the skills you have. Whether than means asking to sit with someone while they do a task or Google-ing how to do something. Whatever it is that you have been tasked with or you find interest in, take the time to learn it without asking your boss to show you or take care of it for you. Remember, you are raising the bar, not ridding the coat-tails.
5. Question everything. Well, not literally everything, but at least stop and question yourself when you think you’ve done everything asked of you. Double check. Think again. Look again. Could you have possibly missed something? Maybe you didn’t miss something, but is there an opportunity for improvement? Perhaps this one won’t produce much extra in your output of quality work as often as the others will, but it will at least keep you thinking and keep you on your toes which can only improve how you are thought of by your peers and your boss.
The point is: raise the bar. Raise it for yourself.
Don’t wait for someone else to tell you the bar is way over your head – at that point the next thing you’ll see is a pink slip.
Raise the bar now. Do more than just enough.
“Anything worth doing at all, is worth doing well.” – Lord Chesterfield
A very common (and sometimes heated) discussion among developers is: “Which is better – C# or VB.NET?” Answers that I have heard have ranged from “VB has a great ‘spell-checker’” (not kidding, that is a real reason that a developer gave to our team) to the statement that “Its the one I work with the most.” In my opinion, the best answer I have heard so far that sums it all up is: “Coding in C# makes you a better programmer.”
Of course, this reason is most certainly arguable and sounds very subjective, and there are lots of other good reasons, but I think that one sums it up the best. Perhaps more than half of those who would read this post will already be disgusted with me for making such a statement and might not even read further. But for those of you who like a good debate, by all means continue reading so you have a fuller context with which to either agree with me or flame me at the end! I am certainly not going to attempt to prove that C# makes better developers, but it is at the very least thought provoking. In fact, I wonder if we asked a group of developers from each side with the same basic skill level to take a short quiz, which ones would write better quality code – the VB or C# programmers? But again, that is not what this post is for.
So why do I think that C# makes me a better programmer? I liken it to how driving a manual transmission makes a me (and most likely anyone) a better driver. I think that manual transmission cars encourage people to be better drivers because there is much more attention to detail required throughout the entire drive time.
There is less opportunity to fall asleep at the wheel when you have to push and pull and coordinate feet and hands than when you only have to move one part of your body a very small distance.
You also have more control over the car and how it operates because there is more of you involved in driving. Your brain is forced to coordinate several things just to get the car moving forward not to mention making split second decisions.
There are also several things a manual transmission does that indicate whether or not you are doing the right thing – the sound of the engine is different, the way the car moves (or lurches) forward or backward, and even gas consumption is an indicator of how well (or poorly) you are driving. Since you are the one controlling all these things, the only way the car will perform better is if you drive better.
Coding in C# has done much the same things for me as driving a manual transmission. It has encouraged (sometimes forced) me to be a better coder because of the attention to details that are required.
When you are forced to think about the names you give things because the mere spelling of that name could cause problems, it is harder to “fall asleep” coding. You have to state explicitly that you are ending a coding thought or what type of variable you are getting ready to declare or whether a variable should be available for the whole project or just the class you’re working in. Sure these seem like small details, but when we are forced to be more involved in our code, we will become better developers just by having to pay closer attention to minor details that make a big difference.
C# also seems to force us to the level of thinking that asks “Are my variables declared properly? Are they initialized? Are they being used and spelled correctly? Should this method actually be private?” etc. It seems like C# starts off believing that you, the developer, know what you are doing so you should tell your code how you expect it to work instead of your program trying to intuit what you meant to code. On the flip side, VB seems to begin by thinking that you might not know what you’re doing so it will try to figure it out for you. That makes lazy developers and sloppy code.
I began my coding career working with VB and I appreciate how it helped me get started and how much it has improved over the past seven years that I have been working with it. However, as I have grown as a developer I have found it less and less sufficient to accomplish my given tasks and more and more cumbersome to actually use. In fact, a colleague of mine the other day said it well I think “VB stands for Verbose.” But whenever I’m in a C# project, I have no problems figuring how how something is supposed to work whether I wrote it or not and I am able to write code that looks better, works better, and is more efficient by paying attention to the details.
I welcome your comments. What has been your experience? Which language(s) do you prefer and why? Is there a language that has made you a better developer?
Developers need to be creative – it is a must. A developer is more than just someone who slings code. A developer combines their coding abilities with their ability to think creatively to come up with good solutions to meet business needs in a timely fashion.
Sometimes the business may have some kind of idea of what they want, but until you, the developer, build it, they are not completely certain. As many of us know, this can lead to drastic, sometimes discouraging changes in projects. However, we cannot let that slow us down and rob us of our creative solutions to the problems the business presents. Yes, the project you are working on might get scrapped at any point in time, but rather than throw up your hands in frustration that your masterpiece was rejected, why not think about it positively – at least you are getting to spend your time coding!
The other side to that might be that the project you are working on doesn’t get scrapped but every time you provide a solution, the business comes back asking for something different or further modifications. Again, don’t let it discourage you! This is a chance to get better. If we pay attention when that kind of thing happens, we can learn to anticipate what the business wants and eventually help to lead them to the requirements determination instead of being dragged along behind only experiencing the after affects.
Part of learning to anticipate what the business wants and becoming a better developer is learning how to ask the right questions. Notice I said the right questions. It is tempting when we get discouraged (especially when we are trying to be creative) to give up and just start asking very broad questions like “what do you want here?” “what do you want this control to look like?” “what should that report look like?” Those questions are not the questions of a creative developer engaged in what they are doing and eager to give the business a solution they take pride in. Those kinds of questions are a sign of a developer who can quickly become a burden and who is called on less and less to participate in writing new code and more and more is given the menial, uninteresting, lacking in creativity, support items any “code monkey” could handle. This is not a place you want to be. Developers must maintain their creativity in order to maintain their edge.
Another mark of a creative developer is one who is always trying to find another way to do things. Whether it is learning to use a new tool to make you a more efficient coder, or coming up with a solution that might sound a bit unconventional, these traits are what help to build great companies, perhaps even your own if you are so motivated.
So what are the “right” questions? If you are a developer, you already have the ability to think creatively about a solution, you may just need to exercise a bit of confidence and put yourself out there in order to keep the project moving forward. Back to what the “right” questions are, think about what you would expect your boss to answer in response to your questions about specifics. Think about how you would answer your questions if you were the boss. After you think about these two things, there are fewer questions left unanswered and you are able to start building your application. The right questions then become questions driven by what you already have in place such as “Is this what you’re looking for?” or questions related to specific business rules instead of just “what do I do?” kinds of questions. There are lots of pieces you can build without specific direction. Be creative! Start somewhere. Is there a risk you might get it wrong? Sure. But, even if you are way off base, you have shown initiative (that’s a word that gives your boss the warm fuzzies!) and you have given yourself the opportunity to grow as a developer, perhaps you will have even learned something new in the process. That is worth the risk!
A developer is more than a coder. Good organizations want developers, not just coders. Develop the ability to use your analytical skills with your creative thinking skills to meet the needs of the organization in a valuable way. Be a better developer.