I find myself looking back over my time in the Tyson IS department as I prepare to make the move to Improving Enterprises. I have tons of fond memories and have learned a lot. I started out never having written a line of C#, and now have taken part in some huge milestone projects. There are some big lessons that I learned that I felt would be valuable to others. Here they are in no particular order.
Always Say Yes
This one is thanks to a friend Rob Tennyson. There is nothing that is impossible. I found my colleagues and I were pushing back against our customers for a lot of reasons, some valid and some not. This push back did two things. One, it created animosity between the product team and the business customers. Two, it gave us an excuse to take the easy way out instead of pushing for the elegant solution. These things can easily be avoided by taking the approach of “Always Say Yes”. If the user wants you to write a program that will send unmanned spaceships to hundreds of planets and safely get them back. Say yes. The time, money, effort, and return on investment should be the determining factors for a request, not the developers opinion.
Seek Excellence in Code
I had three great technical mentors at Tyson. ( Mike Pitts, Rob Tennyson, and Jay Smith) They taught me that even the smallest code problems can cause major headaches. We have had hour long debates over patterns and practices that lots of others thought were pointless, but those debates led to a better understanding of great code. You may or may not work in that environment but I would encourage you to find it within yourself to strive for excellence. Even if excellent code is not your management’s main focus, it should be yours. When you approach a problem you bring with you everything you have learned up to that point. If you do not strive to increase that knowledge as fast as possible you will be doomed to repeat mistakes.
Technical Jobs take Technical People
There are many types of people in the world. Some are the type to be analytical, logical, and procedural. These people when combined with a high level of comfort with technology make what I would call a technical person. These are your programmers, network engineers, software architects. Someone without those skills/that comfort can and do enter a technical job. This unfortunately leads to a problem. The technical folks on the team are forced to either pick up the slack caused by this mismatch of job requirements and skill set, or try to train the non-technical person in the logic and procedural nuances of the job. This hamstrings a technical team.
Training Is Required
Employers that want to keep quality programmers have to put technical training on the priority list. The rest of this is not aimed at employers, but at developers. You have to strive to increase your knowledge and skill set or risk becoming irrelevant. You can have a long career only knowing asp classic or COBOL but you will do that and only that day in and day out unless you branch out in your skill set. This is not only during work hours, but also going to local user group meetings, attending regional events, and independent learning. There is nothing worse than having another developer ask a question and the answer is the first response on Google. Please put some effort forth in your development. If you don’t there is little motivation for others to.
Support Hours are a symptom of a bigger problem
There is the constant battle of reducing support time and increasing project time. This is somewhat valid but I hear the argument that support is necessary and it scares me. Support calls are symptoms of poorly written, poorly tested, and/or poorly defined applications. If you find an over abundance of support hours take a look at the root cause before trying to address this. If there is a minor shift from “Get it done” to “Get it done right” the support time will gradually decrease.
Retrospectives help
After completing a major project (~2000+ hours ) and pushing it out to the first 2-5 locations. Stop. Take 3-4 weeks and clean up the code base. I guarantee that there were things that the team learned while writing the application. These things are apparent to the people coding it. Ask, and listen. Most developers will be attuned to these and are not naive enough to think that they will go back and make it perfect, but they can make it better. Taking that couple of weeks time will save support time and gain feature velocity over the life of the product because the mistakes made early on will not plague the project for it’s lifetime. This 3-4 weeks will help pay back the technical debt that accumulates during the project.
9fc316ec-18a5-408c-ab48-462d40dadd42|3|5.0
Community, Productivity