Getting in the groove of business...

[caption id="attachment_317" align="alignright" width="250"][] Just Me[/caption]Hey All, I have had a lot of recent posts, writing plug-ins, project management techniques, and stuff like that. What I have learned is that momentum is everything. I have enjoyed all the topics that I have covered and have learned a lot about what does not work and what does work. I don't think that process will ever end. I do a little better each time. Today I want to talk about coding and business communication skills.

I always was frustrated when I was just starting out and everyone says, you need more experience. Well, how am I going to get experience if you don't give me a chance. Well, that is why you take an entry job and you don't start as a chief architect. You work up to things. I know that now. Common Response: "Why? I went to school and I studied computer science, I know all the techniques!" Yes, you probably do. However, you have NEVER applied them to real world scenarios when time, money, and unfortunately egos/politics come in to play. You have the ideal solution for the basics, the ground-up design. You don't have any idea on how to integrate a new feature into a 10-year-old product running on 15-year-old hardware. The common response is, "upgrade the hardware, then rewrite it with new technology". The problem is the rewrite will take 6 months and the feature needs to be done by next Friday. So what happens? We compromise and patch that feature in and it works, and we get the sale, and we move forward. That is reality. Now, as a software developer, we should understand design patterns and figure out the most elegant way to add that feature so we can turn it on and off easily, maintain it without a 104 layers of abstraction, and make sure it works (insert test criteria HERE). However, I have seen in a single code base, multiple ways of retrieving data from a database. It all depends on what developer at the time wrote the code.

I ran a small software company called Chameleon Coding, I choose that name for that concept of you should never know who wrote the code, it should all look seamless and beautiful. I would change my coding style to match my clients current base and improve it where I could. They rarely (ok, I can't actually think of a single time) asked me to rewrite their entire code base. They would want this new feature, or migrate to this new technology so they can tell sales they are .Net 3.0 and use jQuery. They didn't know what that meant but that is the buzz words that clients look for so they needed to be able to say that legally. One MVC page and a client control and tada, they can now say that.

All of that rambling just now leads me to one solid point -

Write Clean Code

If you try to do that, you will come closer than if you didn't. I do not write clean code 100% of the time. But I always have that in my mind... so each time I touch a code base, I try to write a little bit better code. I learn a new language and my code is horrible... but by 2 iterations, it is as elegant as if I wrote in C# from the start. I have learned practices, styles, and coding techniques from many different people. I did not say BEST practices, or elegant styles. I did that intentionally... we learn all sorts of things, we google for code snippets, and often those snippets work great. But is that CLEAN CODE? Maybe not. So don't become a C&P engineer (cut/paste for those who didn't know), write real code. If you do use a sample, review it as if it was your own, because you are about to claim it. The business will always push you to work faster, but it is up to you to work smarter and cleaner. Business is driven by money, if you can explain how taking 2 more days can save them $10,000 in the next year, because it is easier to maintain, faster to update, and faster performance, they will have a difficult time arguing with you (they still will argue, but it will be more difficult for them). So to all the graduates of Computer Science, yes, you are an amazing developer and you have a great toolkit. Now, learn the business mentality, the feature drive, the process of releases, what is a marketable feature and what is simply a nice-to-have for developers... be patient, and listen. The world is ready for you and your talents, but now you need to understand how the world communicates, and it is not always based on logic, but on emotions, greed, and fear. You can change that tone but be willing to stand up for that change and possibly create it yourself.