thoughts on coding and everything in between
Tag Archives: 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.
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.