Knowledge Transfer

My direct manager for the past two years has decided to leave his current position in the firm to look for other opportunities. Our CTO said that he “had served his time with the company.” To which I responded, “You make it sound as if it’s a jail sentence to work here.”

Over the last two days my manager was in the office, the whole development team spent that time with him in knowledge transfer sessions. Earlier this year I wrote about past knowledge transfer sessions with a former colleague. What follows are a few words of advice from my former manager which he gave us before his departure…

Use standard off the shelf components whenever possible, replace our custom ORM component with Hibernate, replace our client scaffolding code with NetBeans Platform. Use, reuse, and make use of open source software, don’t reinvent the wheel. In essence work smarter, not harder!

When things are built right, nothing is heard.

If you want to scale up, you need to follow the chosen process. Doing software consistently requires strong discipline and a process that fits the given environment. Nothing should be done heroically, don’t ever say “Ooh, there is a critical bug, let’s stay overnight, get high on caffeine, and come up with a temporary hack.” Software development is not a sleep over party.

Doing business software is not a challenge, developing software consistently, and scaling up is the real challenge.

An intelligent release system is integral to the success of a software organization, if you think about it, code is your bread and butter and your release system is what bakes it. You need to be able to branch, build, test, and release in a painless, hassle free, and error free way. Again, your build system is an area where you don’t have to be a hero, don’t prove your manhood or mad hacking skills with one off patches. In regards to the build system, and most business processes in general, if you have to do something twice, automate it.

When working in a development team with a lot of smart individuals, it often doesn’t matter which solution is the ‘best.’ Any solution that works that is simple to maintain is good enough. The key is to debate, communicate, and follow through with commitments! As Larry Wall says, “There is more than one way to do it.” Just make sure that whatever you do, you do with integrity.

I have never seen a company fail due to a specific technical problem or limitation. I have seen companies not scale up their business and talent pool.

Find a chance to do a deeper level architecture. Take on more responsibility, demand a major chuck of functionality and own it from analysis, design, implementation, and testing. When you have a certain breath of knowledge what you need is a certain anchor point so as to not get lost in the noise.

Especially for a small shop like us, be aware of the psychology of the development process. Once you bozo bit a guy, it is really hard to re-engage him. I have seen a guy become a star player, to later burn out and quit.

Business logic is hard only to understand, not to develop. Once you understand the requirements and the domain, the code follows. What is hard is building a scalable system and learning what you are building. Analyze, design, and comment, test, and think the problem first before coding.

Technorati Tags: , , , ,