Between The Code
thoughts on coding and everything in between
No Pain, No Gain – Code Katas
Code katas are not a new concept at all, but my recent participation in daily katas has compelled me to consider how valuable they really are.
I won’t bore everyone with the technical definition of what a kata is; a kata is basically a specific thing you do repeatedly in order to improve in that area.
For me, no matter what it has been that I have had to practice (studying, playing the violin, coding, etc) it has always been painful & difficult, especially in the beginning. But that’s kind of the point isn’t it? If it were easy, then I wouldn’t need the practice. It seems to me that there are some people out there for whom certain things just come naturally, but, as tempting as it may be, we can’t let ourselves get caught up on the abilities of some in such a way that it distracts us from using regular practice to improve ourselves. Instead of comparing our abilities (or lack thereof) we need to just work hard at getting better if we really want to be good (dare I say the best we can be?) at our craft.
Maybe you stumbled upon this blog post because you don’t know how to do a code kata, or because you need some encouragement continuing in katas, or perhaps you have lost all interest in regular, consistent practice – here is just a bit of advice I would have given myself before my first code kata:
1. Don’t quit & don’t make excuses. Sure, it will be hard and frustrating (or boring) sometimes, but the point is to get practice – that’s it. So just do it, and keep doing it.
2. After coding a problem kata to its solution, scratch it and start over from the beginning. You just might come up with a better way to do it or if nothing else, you will get practice with how quickly you can put it back together again.
3. Code kata for a maximum of 30 min. Keeping it in short sprints will help you get faster, it will force you to get & stay focused, and also gives your brain a break & a chance to work on something else.
4. Do a code review after you are done with your practice time. Have a co-worker or colleague open your solution and talk through what it is doing. Having to be accountable for the code we write helps us to learn and keeps (or makes) us humble.
5. Try something new – a new problem, a new language, a new code reviewer, no mouse – anything to mix it up and stir up any area that needs improvement. It is also a good way to avoid boredom.
6. Take constructive criticism and learn from it – let go of anything else. Constructive criticism seeks to teach you the better way, but any other negative or derogatory remarks or feelings do nothing to help you out so learn & move on.
7. Don’t be intimidated by the exercise. Don’t feel like you should know it all right away – that defeats the point of the kata. Of course you won’t have the best solution right away. We practice so we can learn and get better.
For those of you who want to continue improving your development craft here are a few kata websites my team and I have used. If you know of other sites, please share them – or come up with some of your own! Happy coding & good luck!
http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue
Raise The Bar
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.
Please.
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
On The Hunt
Time To Go
“We’ve sold the company and over the next few days we will be helping everyone find new opportunities.”
This is not a statement anyone wants to hear at a company meeting. This year, I was one of those employees. It left many people scrambling to make themselves more marketable in just a short amount of time.
Developers were (thankfully) already in high demand and thanks to some terrific leadership, everyone was more than marketable – in some cases we were too relevant as many of us were soon to find out.
But I didn’t just want a j-o-b, I wanted to enjoy my work and look forward to going to work every day (or at least most days!). I wanted to work for a company that I could respect and that respected me & my abilities. I wanted to work in a place that I could help make a difference, improve processes, and participate in making the company great. I wanted to work for a place that would challenge me to think smarter, not harder, and would set me up for further success in my career.
Less Than Appealing
A person looking for a job very rarely has the opportunity to be picky. After all, no one (and no company) is perfect, but there were definitely some interviews where I tried not to run back to my car or hang up mid-sentence! As a prospective employee I was prepared to be a good interviewee, but I certainly was not prepared to be poorly interviewed. I have had the privilege of sitting on both sides of the interview desk but I wasn’t prepared for those who interviewed me to do a bad job.
After being back on the interviewee side of the table again, I have a few recommendations for hiring managers:
- Remember the person who you are interviewing considers time a valuable resource just like you do. Don’t assume that just because they are looking for a job that they have all the time in the world to wait on you or shoot the breeze. If you say you are going to do a 30-45 minute phone interview, don’t let it run into 1.5 hours. If your procedure is to have an interviewee take a test, have the test prepared ahead and make sure an appropriate amount of time has been allotted and communicated for both test and interview.
- Be honest. Do a reality check of your environment and team. Be prepared to share honestly what your interviewee will be getting themselves into if you decide to hire them.
- Include a couple of the people who may be on their team. This is another way of a reality check for both you and the interviewee. It also lets your team know they are valuable and that they will be an important part of the successful addition of a new team member.
- If you start with a phone interview, make it useful. Fifteen minutes of “do you like to code?” or “what do you think you want to do” is not helpful or informative to you or the potential new hire. You both should be able to get a good sense of whether or not it will be a waste of time to conduct a face-to-face interview.
- Pay attention to the right details. You might think all hiring managers are attentive to the details, but that is actually not a genetic trait of managers. You need to know what the interviewee expects from this job (pay, start date, benefits, etc). There’s no need for them to beat around the bush – it is a factual part of a job and one that shouldn’t cause surprises to either party. It is even more important to notice behavioral details. Just because someone “knows” thirty programming languages or they passed your test with flying colors doesn’t make them an automatic hire or the right fit for your team or organization.
I have been very fortunate to be part of a great leadership team I can very proudly say that we almost always did these five things (nobody’s perfect!). However, through this process I have seen more than a few hiring managers not do one or all of these and they have paid the price (as have some of their new hires).
Not The Only Ones Responsible
As a prospective employee, I worked hard at making sure the person interviewing me had no reason to dislike me and even the interviews that I couldn’t wait to get out of I did my best to make the interviewer feel good about having me there. I would not ever recommend that someone looking for a job do anything different. However, you definitely need to be taking mental notes & know what clues are being given that will help you love it or not.
As an interviewee, here are the things I was (or should have been) looking for:
- Are they prepared? I’m sure sometimes this is a tactic used by managers to test a stress reaction, but I actually think that is poor leadership. A good leader should be displaying the kinds of behaviors they expect from their employees. “Attitude reflects leadership, Captain” (Remember the Titans) If you want to be an excellent employee, don’t go to work for someone who doesn’t lead you in that direction.
- Are they using current technologies? It doesn’t have to be bleeding edge, but if the company is going to move forward they will have to be keeping up with current technology. If cost is the excuse, then consider how they might look at paying you. If time is the excuse, then consider the schedule you might be expected to keep. If they don’t have time to ever do things the right way, that indicates poor time management & unrealistic deadlines. If the reason is “That’s the way we’ve always done it.” then consider if they will be able to sustain growth (including your own) and if they will really care about your ideas.
- How do they treat or view their current staff? If there are a lot of secrets to bringing you in, then consider how often you will be communicated with. If they talk down about the staff they have (especially if they are saying how great you are in comparison) consider how they might talk about and think about you when you’re not around. Do they invest in their teams & the workspace? Do the other employees connect with one another regularly about non-work things? You will be spending approximately half of your week there so consider the affects the environment will have on you.
I’m sure you can come up with more things to look out for as well, but of course during the entire interview it is never a good idea to give them the impression that you don’t want to work there. You never know, you might wind up with no options for the time being, so don’t shoot yourself in the foot.
Keep A Sharp Eye Out
Regardless of whether you stay or leave a company and regardless of the reasons why, these are always things to keep an eye out for because people and companies are always changing. Make yourself an excellent employee and expect excellence from your leadership.
A Beginning Journey Into XQuery
I received a request a few weeks ago for some data that we only have stored in an XML field in one of our tables. The reason for storing the data as XML is not as important as how we were going to go about digging through the data to provide a tabular representation of the relevant pieces to satisfy the request. It took quite a while for me to catch on and get the data I needed that was buried several levels deep in the XML which spurred me determinedly to have a better understanding of how to accomplish similar requests in the future, hence this post.
The first thing I needed to do was get a handle on the XML itself. As with any complex task, it is usually best to first break it down into the smallest piece consumable and understand that first so that you have a solid starting point. So the first thing I did was to grab just one row’s XML string stored in my table and play with that first. I set it equal to an XML variable so that I could easily query the nodes in it and then just wrote a simple query that selected one value from the XML text.
One very important thing to note is that in order to get at the Customer’s Id buried several nodes deep, my “table” being queried has to include the nodes leading up to the Customer node. In other words, I couldn’t just assume that the query language understands that “CommissionedFor” is my root node – I have to tell it that. What results do you get when you leave out the root node?
Unfortunately you don’t get a lot of help from the sql compiler to figure out what could be causing this utter lack of data so the most important thing I gleaned from playing around with XQuery is to know the XML you are querying! The more child nodes that are present the more complex the query could potentially become and the greater the need will be to know where the root is and where each sub-node begins & ends.
Another reason that its good to have solid knowledge of the XML you are querying is that you need to know if you have any XML namespaces defined because if you do, that can potentially change the entire way your query works and again you might be left with a big fat NULL if you don’t have your namespaces identified correctly. The XML I was attempting to query actually had two namespaces: a default namespace created when the object was serialized and our own namespace. Working with one namespace is tricky enough, let alone multiple namespaces (http://beyondrelational.com/modules/2/blogs/28/posts/10318/xquery-lab-37-working-with-multiple-namespaces.aspx)
After much searching and finally figuring out I had to mess with namespaces my simple query got a little more complex:
I finally got my “simple” query working and now it was time to plug in the actual table where this information was stored so that I could aggregate the XML data across a range:
There were a few “gotchas” here for me:
- Of course the fact that there were two namespaces as part of my root node from the get-go. Everything in the query is important, so be purposeful about which namespace you use as the DEFAULT (if any). I actually found having a default namespace to be easier for my purposes than aliasing each namespace.
- There is a semicolon at the end of the declared XML string! Without the semicolon in this particular case I get the error message “Incorrect syntax near the keyword ‘with’. If this statement is a common table expression or an xmlnamespaces clause, the previous statement must be terminated with a semicolon.“
- In order to create a unique row for each Id I had to learn the use of CROSS APPLY which at the most basic level is just joining the “columns” in your XML to columns in your table. The equivalent in TSQL is INNER JOIN. The equivalent to a TSQL LEFT JOIN is OUTER APPLY.
The title of this blog post indicated a “beginning” and I think I have dived deeper than just a beginning, but hopefully I have kept things relatively simple enough that some of the key needs for querying XML have been demonstrated without being too overwhelming.
No Pain, No Gain – Code Katas
Code katas are not a new concept at all, but my recent participation in daily katas has compelled me to consider how valuable they really are.
I won’t bore everyone with the technical definition of what a kata is; a kata is basically a specific thing you do repeatedly in order to improve in that area.
For me, no matter what it has been that I have had to practice (studying, playing the violin, coding, etc) it has always been painful & difficult, especially in the beginning. But that’s kind of the point isn’t it? If it were easy, then I wouldn’t need the practice. It seems to me that there are some people out there for whom certain things just come naturally, but, as tempting as it may be, we can’t let ourselves get caught up on the abilities of some in such a way that it distracts us from using regular practice to improve ourselves. Instead of comparing our abilities (or lack thereof) we need to just work hard at getting better if we really want to be good (dare I say the best we can be?) at our craft.
Maybe you stumbled upon this blog post because you don’t know how to do a code kata, or because you need some encouragement continuing in katas, or perhaps you have lost all interest in regular, consistent practice – here is just a bit of advice I would have given myself before my first code kata:
1. Don’t quit & don’t make excuses. Sure, it will be hard and frustrating (or boring) sometimes, but the point is to get practice – that’s it. So just do it, and keep doing it.
2. After coding a problem kata to its solution, scratch it and start over from the beginning. You just might come up with a better way to do it or if nothing else, you will get practice with how quickly you can put it back together again.
3. Code kata for a maximum of 30 min. Keeping it in short sprints will help you get faster, it will force you to get & stay focused, and also gives your brain a break & a chance to work on something else.
4. Do a code review after you are done with your practice time. Have a co-worker or colleague open your solution and talk through what it is doing. Having to be accountable for the code we write helps us to learn and keeps (or makes) us humble.
5. Try something new – a new problem, a new language, a new code reviewer, no mouse – anything to mix it up and stir up any area that needs improvement. It is also a good way to avoid boredom.
6. Take constructive criticism and learn from it – let go of anything else. Constructive criticism seeks to teach you the better way, but any other negative or derogatory remarks or feelings do nothing to help you out so learn & move on.
7. Don’t be intimidated by the exercise. Don’t feel like you should know it all right away – that defeats the point of the kata. Of course you won’t have the best solution right away. We practice so we can learn and get better.
For those of you who want to continue improving your development craft here are a few kata websites my team and I have used. If you know of other sites, please share them – or come up with some of your own! Happy coding & good luck!
http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue
C# and Manual Transmissions
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?
Practical Troubleshooting Advice
It may be more glamorous to develop new code, but troubleshooting is something we all will have to do at some point. While it may not be as much “fun” at times, learning to troubleshoot well can serve good purposes as well such as making us better at our craft (if we are paying attention). Here are some points of advice that I have found helpful in getting to the root of a problem in a timely manner. This list is certainly not complete, and I welcome any additional points others of you have found helpful.
1. Know the starting point. This is more than just having the error or bug report. You need to pay attention to the details about the problem. If you are getting an error message while debugging, don’t just skim it, read it carefully. The same goes for any error – pay attention to the information given. If the problem being reported is from a user, you will most likely have to do some detective work to figure out you true starting point. Know your users. Who is reporting the error? What were they doing when they got the error? Do as much information gathering as you can before you start troubleshooting to find and fix the problem which leads me to tip 2.
2. Reproduce the error. If you can reproduce the error following all the same steps the user followed you will have a lot more information to work with and you will know where to start debugging. Keep in mind in reproducing the error what the environment of the user was at the time they got the error – the steps they took, their setup at the time of the error, and what they expect to see are important.
3. Take the reported problem seriously, especially if it has happened more than once. Don’t fall into the trap of “that always happens” or “that person is always saying something is wrong”. When you start thinking that way, you may possibly miss a real issue and then have to stay late to fix it! And don’t let that kind of thinking blind you to the real solution.
4. Don’t make assumptions. If you think something is happening but don’t have the proof for it, you are much more likely to miss the real solution to the problem – then you will have wasted time researching the wrong thing and of course the problem with remain unsolved.
5. If you are debugging code, be purposeful about your breakpoints. Breakpoints should be placed in logical locations and if you have done the work of tips 1-4 you should have a better idea of where it makes sense to place breakpoints. If you find yourself stepping through multiple methods and more than one class, think about whether or not you really understand the problem and if you have enough information. Revisit tip 3 – have you reproduced the error first?
6. Be familiar with your debugging tools. Some languages of course may not have rich debugging tools so you might have to get “creative” with things like inserting output strings or select statements to let you know what is going on throughout the process. However, don’t miss out on free tools that are out there! If you find yourself thinking there should be a tool to help you debug, go search for it. It might even be that your development environment already includes these tools but they aren’t immediately apparent so again, ask for a little help from the community.
7. Ask for help. If you have people on your team that are more familiar with the application, don’t spin your wheels for more than 30 minutes before asking them. They just might have some great knowledge you need. There are also great tools on the internet like Google, Stack Exchange (previously Stack Overflow), MSDN, user groups & forums, etc. You have to have a good grasp on your problem of course so before you jump into using the internet to solve all your problems, make sure you have taken a look at the tips prior to this.
8. If you think you have found the answer – re-verify. Take a second look at why you think this is the solution. If it sounds like what you think is going on is an impossibility, it just might be! Are there assumptions you have made? If so, go back and prove them. Think about how to explain the solution – can you put it in simple enough terms to give an “elevator pitch”? Can you explain it to your boss and answer all the questions he will have? Also use your development environment to try to apply your solution and see if the problem goes away. This of course should only be attempted if you have been able to reproduce the problem first!
9. Do better! Once you have found the source of the problem, have verified it and rid yourself of assumptions, look for how the code can be improved, not just fixed. If you have time, re-factor mercilessly! If you don’t have the time, at least take the opportunity to make small improvements rather than quick patch jobs. You don’t want to have to come back to this next month and fix what you fixed!
10. Document. I can hear the moans and groans from the other side of this blog posting, but before you fall on the floor in a pretend coma the kind of documentation I am talking about is just to detail in a work item or knowledge base somewhere what the problem was, how you found the source of the problem and what you did (or are doing) to fix it. This documentation should be specific, have enough detail to provide good context, be short enough to fit into about two paragraphs (or less. If you happen to be the one to have to go back to this later, you will be glad you took 5 minutes to document your troubleshooting! Just think how quickly all this troubleshooting would have taken if you would have had this documentation from the start!
Creativity & Asking the Right Questions
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.
Developer-Think
You’ve heard of group-think? The “tendency of the members of a group to yield to the desire for consensus or unanimity at the cost of considering alternative courses of action.” (http://www.businessdictionary.com/definition/group-think.html)
I think in the world of software development we have to be careful not to engage in “developer-think”. What I am calling developer-think I am going to define as the tendency of a developer or group of developers to disregard effective and real value-added design and development for the sake of what makes sense to them.
When presented with a new project, it can sometimes be challenging for the developer to stay focused on the task at hand. Mind you, I am not saying that features should never be added to the project! If the feature can be added without costing more than the value added it could be considered. However, if the developer wants to add the feature to increase the coolness factor, or to make it conform to a particular coding practice, or to just blindly do whatever the user requests, it would be better to leave it alone or at least give it some additional thought time first.
My boss actually has a very realistic point of view here “The faster you can get your project released, the less time the customer has to come back with questions or changes that will put the project behind schedule.” I think more developers should think that way! There can always be a phase 2 or 3 or whatever, but a project that is scheduled to take three weeks that turns into six months has some serious issues! Before you pass the buck, consider that it very well may be due to “developer-think”: not understanding the end user’s needs and requirements, over complicating a solution, feature creep without value added, and I’m sure we could think of more!
Some developers are very intelligent people who develop brilliant pieces of code in only a few hours. These brilliant developers, if not careful, can add complexity, and within a group who respect and admire their work, those same brilliant developers can easily lead the entire group into developing a security access application for a nuclear power plant instead of the requested simple login screen for a blog (just example).
Some developers are so focused on thinking analytically and logically they forget to think about the way the users leverage the application and in the worst cases of course, completely and purposefully disregard the users. But they don’t seem to remember that without the user, they just have an application that no one uses! I have been in places where users didn’t want to have anything to do with the developers or anyone in I.T. and as a result the projects are either very difficult to complete or hold no interest what so ever. Everyone who wants to work in that environment raise your hand! No takers? Huh. Maybe we should treat our users as a valuable asset to our work. For those developers who don’t like users, maybe its time to take this sage advice (slightly modified) “Keep your friends close, and your users closer”.
A third pitfall developers fall into is adopting a “cool” new coding practice without counting the cost. We have all read or seen something new and cool that either would make our lives easier or would be awesome to implement in our current application. Sometimes, with the right project and the right time allotment, we can actually implement some of those enhancements. However, the danger is in getting off target and making the project run a little late (or a lot late). This could lead to more time for user feature requests, open the door for visible possible enhancements, or just simply slow down the work of your team. Again, sometimes its worth it, but the cost needs to be counted first. In a good, agile shop, developers should be ready to release early, release often, and continue to keep the projects moving forward.
A good group of developers recognize these behavioral tendencies within their group and will work together to help each other stay away from these pit-falls. How can you tell if your team has succumbed to “developer-think”? Start with some of these evaluative questions: How agile is your shop? How long does it take you to release a fully tested medium-to-large sized project? What is your relationship like with your users? Do they value you or talk bad about “I.T. people” every chance they get? If those questions can be answered positively, you are probably on the right track already, but remain vigilant and keep them positive.
Between The Code 