a wise man learns from the mistakes of others!
This is a list of things that I have learnt in my stint in the IT industry. I thought that everyone knew these things but as is often the case we take for granted the knowledge we have gained via experience.
Everyone knows better than you.
This might sound sarcastic but it is not. When you come fresh out of your studies you figure that University or College has prepared you for everything. Every eventuality, every possible problem until you walk into your first job. What you fail to realise is that while studying you have been given the perfect environment to build programs. You are the only person responsible for your projects. Things can be configured and set up as you please (unless the assignment stipulates otherwise). Finally you never have to worry about the bottom line. By the bottom line I mean money. Sure you have to worry about marks but see how confident you are to make tough decisions that affect a companies bottom line. Listen to your peers, interact with them, make suggestions but be prepared to be corrected. You might very well have a good idea but it doesn’t fit the business problem. On the other hand you might have an idea that solves the problem. Business software development is a team effort. Be part of the team.
Learn when to keep quiet.
- Your opinion counts. Really it does. When you express it is a different story. There are times to speak and times to keep quiet. If you are not sure whether it is time to speak or time to be quiet then it is probably best to be quiet. Don’t be afraid to speak though but before you speak, formulate your questions. Think about what you want to say and what you are trying to get answered. When you do speak make it concise and to the point. Leave no room for ambiguity. Don’t ramble or speak for the sake of speaking. Nothing turns people of your statement, no matter how smart it is, quick than rambling or disjointed statements. I often remind myself “Light travels quicker than sound. That is why people appear intelligent until they open their mouths”.
Don’t get precious about your project.
This does not mean that you are to take no pride in your work! What this does mean however, is don’t get so attached to what you have done that you refuse to improve it because it wasn’t your idea. Perfection is obtained through iteration. Nothing screams insecurity more than an individual who gets defensive about their code. Never forget that a software project is a strange beast, it can turn at the drop of a hat, hence all the agile methodologies now prevailing. These are not fancy management techniques but techniques put in place to help negate the dynamic nature of business and the rigged nature of software development. If you believe you are right, converse with the individual claiming there is a better way to do it. Perhaps they might educate or their reasoning might illuminate and angle you never thought of. Then again, you might very well educate the individual point what they believe to be a problem out.
Be professional.
Ok seriously. We have been potty trained. All of us. We have all figure we were old enough to rule the world and we most definitely thought we knew everything at some stage or another. That being said, why is it that when we first walk into the work place we become a bunch of snivelling cry babies? If faced with a difficult situation, evaluate it. Don’t throw a temper tantrum when you don’t get your way. Always remember that your employer is your client. You are a service provider, nothing more, nothing less. Do you job and do it well. If faced with a difficult situation tackle it. This is not only in the code base but also interpersonal relationships. If you have a problem with a fellow employee resolve it amicably. You guys, after all, are going to be spending a significant amount of time together. Deliver what you commit to delivering.
Be disciplined with your work. Check it before you submit it. Proof read the document before you submit it. Take pride in your project. The reason I said project as opposed to work is because their is nothing stopping you from continually checking the quality of the project. If you are a more experienced developer and you identify issues don’t just bounce it back to the developer. Take them time to help them fix. I have noticed that a significant amount of errors are due to a lack of understanding as opposed to laziness or stupidity. In this dog eat do world we have created we forget that we should carry the weak. Enable someone not to make the same mistake again, actively promote developer growth and maturing as opposed to bullying. The sooner they can do your job, the sooner your work load can be lightened.
You going to have to wipe your own bum.
I cannot tell you how often I have seen (and yes been one of them) guys sitting in their office fuming at the fact that they can’t do things better because their managers won’t let them. Remember that your working environment and your perception of it, rests completely in your court. If there is something you want changed and it doesn’t go against company regulations then change it. If you think there is something that will fix your development cycles and the risk is minimal to the project, change it. If there is a piece of code that you know can be better, or a piece of refactoring that would remove duplication without bubbling significant issues up the code chain then do it. Don’t expect your managers to hold your hands with everything. Be proactive. Identify issues and figure out how to solve them. There is nothing worse than someone that continually points out problems without a way to fix them. If you put yourself out there and make yourself noticed people will take notice. Don’t sit back and wait for things to happen. If you can improve things then do it. Just don’t step on toes or hurt people doing it. Hurting someone does not imply that you should not be honest with them. It implies that you should not be dishonest with them.
Fill the gaps you identify.
If you notice a gap, fill it. If you can assume a little more responsibility for the benefit of the team then do it. If the leadership needs help then provide it. Don’t just do what you told, do what you see is not getting done. Before you get all mad just take a minute and think about it. This statements does not mean working yourself to the bone. It means that if you can take up a little slack then do it.
It is a team effort.
As software development has matured so have it’s processes and methodologies. That being said, a significant number of old stable teams have been using a form of Agile before it became a catch phrase. Old stable teams have worked past all their teething issues. They have identified the optimal communication mechanism that they should use when addressing their team mates. They understand (you need to understand this so read it again if you have to) that the delivery of a section of the project is not the goal. It doesn’t matter how fantastic their piece of code is. If the project fails then the team has failed. Period. If your team does not produce the end result you have failed. Yes, don’t argue, no excuse, I don’t want to hear you did everything you were supposed to, you failed. End of story.
Be low maintenance.
By this I mean that you should be fluid. Adapt to your environments and situations. Look for ways to best fit in. Be a problem solver. Even if your solution is the best one, try and help. Refer to the first point though. There are ways to communicate your ideas without screaming and making a fuss. Don’t whine about things that annoy you, fix them or suggest ways to fix them.
Business is right.
Yes it is. Sure they know nothing technically but I got bad news for you. If business doesn’t make money, neither do you. As opposed to fighting business become an ally. Facilitate their requirements, even if they seem absurd. This doesn’t mean that they should dictate implementations or technology spaces. This just means that if they request a change then best we perform it. If they request a feature then best we create it. Business is an extremely competitive industry. Being first to market means a competitive edge. The more money business makes, the longer we get to keep our jobs. Lets work with them. The more flexible we are, I have seen this, the more flexible and understanding business becomes.
Get to know the network engineers.
This is something I learned very quickly because I used to be one of those guys. People, for some reason, see network and infrastructure engineers as the plumbers of the IT world. This could not be further from the truth. Remember that the machine you are working on, the telephone you use, the server you hosting on, the network transmitting all your data is because of these guys. If anything ever goes wrong you going to need them to help you fix it. If you are certain there is an issue with the network then take as much data as you can to the network guys so they can diagnose the problem quicker. It is absolutely incredible how busy they can become when you need them if you have been off towards them. I also find that network engineers are generally the funniest and comedic of any division in the IT industry. If you ever need a laugh, go chat to your network engineers.
I am sure there are more but this is all I can think of at this time. The reason I raised this is due to a discussion we had in the office today. If you want top excel then don’t be afraid to stand up and be counted. Fail fast, that way you can move onto the next thing. I have noticed that companies promote initiative even if the answer is not 100% correct. Believe in what you are saying, if you don’t then don’t put it out there. If you put your ideas out there expect them to get cut off. Be prepared to defend them but never defend them subjectively or emotional. Always back your statements up with facts or experience. If your idea doesn’t get accepted then don’t get down or think no one loves you. One day, grasshopper, you will have an idea that everyone loves.
If you don’t agree with the points above you will one day 
As I always say, I am always right, most of the time.