Ted O'Grady

The journey

One of the ways to tell you are on a great team is when building software is fun. The act of modeling problems and translating it into code requires lots of concentration, skill, creativity and, (surprising for some) interaction. Coding can be a short jaunt, or a long journey.

The coding tools

Software is like any other trade. Knowledge makes it happen, but you must have good tools. Simple tools that make the job easier for you are essential. You'll find that many people are passionate about the tools they use. Just ask the IntelliJ and Eclipse communities which tool is the best and you'll get interesting answers.

At the very minimum you need the following: A version management system ( CVS still works, SVN is good too) Backups to keep your work safe An automated build A deployment environment for your testers and users to try A bug tracking system A good IDE (eclipse, and intellij, or even emacs, work for Java developers, Visual Studio is a start but you need to get some refactoring tools for it to make it great) Something to run your tests

 

All of these tools or variations of them can be bought or you can get for free. You'll need to spend the time to put them together on a server for your project, or you can buy a server with all the tools you need at http://www.itfordevelopers.com/. Alternatively, Google code provides an SVN source repository and bug tracker for free. The eclipse IDE is free.

The team

The team you work with is really important. You'll need project manager(s), business analyst(s), tester(s), salespeople, marketer(s) and developer(s). Often that team is only one person, YOU! You just need to realize all the different roles you are playing and balance them accordingly.Lots of single person teams fail because they assume they just have to develop.

I find building your team to be the best it can be will be the biggest challenge you will ever have. You can read about building great teams on my High Performance Teams page.

The product

You are not coding, you are building a product. Make sure you think of the product not just the code. Try and drive your development from the product rather than the code. Working on a purely technical problem is a smell. It often means you are off track. Make sure your business cares about the technical problem.

Coding

Being able to code means you need to be comfortable in the language of your choice as well as basic computer science concepts. Having the syntax of the language at my finger tips reduces the number of interruptions when I am trying to model the problem.

Being aware of the options in your language, and knowing how to find other pre built components is also useful. Building technical pieces (such as message queues) from scratch is expensive and wasteful. Use what others have built and tested and you'll be ahead of the game.

Modeling

Building software is not about writing programs. Building software requires you to: break down the problem into small enough pieces that can be understood, built, and tested create and continuously refine a model in the code that allows people to change and modify the code create and continuously refine a user interface that allows the user to understand how the program works These all require modeling skills. Modeling skills are different than coding skills in that they have little to do with the language and they are difficult to teach.

 

In your early years, as a junior developer, you will be apprenticing, learning modeling skills from the senior developers. You'll discover the usefulness and limits of patterns, the importance of being able to draw a square box on a scrap of paper, and the essential skill of communication. Read the Gang of Fours Design Patterns, and look for them in the code that exists, look for where they could be used, look for where they don't apply. Learn the features of your language of choice. Learn and use a couple of more languages. Figure out how trivial it is to learn a new language.

In your later years, you'll now only be training the junior people in the trade, you'll constantly be learning new modeling skills. Reading books, papers and blogs will make you one of the great developers on your team. If you want to be a technical leader, read Kent Beck's "Implementation Patterns" and Martin Fowlers "Refactoring" book. Move on to Eric Evans book "Domain Driven Design". These (well earlier versions) formed the basis of my senior development years.

Go beyond most senior developers. Read and understand Abelson, Sussman and Sussman "On the structure and Interpretation of Programs". Find an implementation of a garbage collector, understand it. Write an assembly language program to capture key strokes. Push the limits of your abilities. It will give you a deeper knowledge of modeling, limits and abilities of computers, than most of your peers have.

In your senior years you will be able to make your code agile. Agile isn't just a methodology, it is a way of thinking and doing. How do you make your code support change, without building giant frameworks? Have this skill and you will build a better product for your customer.

The detective in you

One of the big differences between junior and senior developers is their level of surprise. Junior programmers are surprised when their code doesn't work. Senior developers are surprised when it does.

Often you'll get the feeling that things aren't quite right in the code, or something is wrong with your understanding. Pay attention to it! That little voice in the back of your head going "uh-oh" has a point. I makes you a better developer.

Interaction

A skill that is as important as your ability to code and model, is the one that says you must be able to communicate. Communication is important, because you must help your users organize their thoughts, extract information from them in an effective and efficient way and finally communicate your solution back to the user.

Communication is a two way street. Many developers are really good talkers. Being a good listener sets you apart from the rest.

You'll need to interact with your project manager, sales people, potential future customers, potential employers, other developers, testers, designers and business analysts. You'll need to present your work to small groups, and potentially large ones.

If you learn to communicate effectively, you will have a long successful career in software development.

Discipline and learning

"Discipline is what you do when no one is watching." - Michael J. Fox Complex problems require discipline to solve. Without discipline things quickly fall apart. Keeping your code in good shape, testing thoroughly, and being careful require discipline. If you follow a methodology (such as agile or waterfall) discipline is essential to it. Failure to follow your methodology, or assuming you know better when you don't, results in failure. Failing to adapt it when it isn't working is just as bad.

 

Learning requires discipline. You need to be constantly learning. Not only is our field constantly changing, with the introduction of new technologies every day, but it is also wide and deep. Sometime solving your currently problem requires learning new skills. On one project, I had to learn about how RAID drives interact with Oracle databases to help my customers solve a performance problem with our product.