Coding by mistakes

All software design companies recognize how important it is to let its programmers make mistakes, as long as they have an established process. The idea of a branch-and-merge mechanism in version control software reflect this; the designer expects to experiment, make mistakes and fix everything before merging his code back into the code. While the programmers are not encouraged to make mistakes, making them in as safe a way as possible very often grants a team the freedom to make happy mistakes, where they learn a new trick, a simpler interface might be used or new approaches or functionality might be invented.

The team still has to work on a schedule, but the confidence to experiment new things is the first way to learn and improve. I believe it’s the best way of turning a team from good to great, especially if I use an agile approach.  I recently saw a funny video about ‘The Institute of Mixing Random Things Just In Case the Result is Good” – it had a better name, but you get the idea.  Random tests, mutations and errors are 99.999999% bad, but sometimes, very rarely, they are useful.  Awareness of it is important and encourages the open mind necessary to realize that an unexpected result might have a positive impact.

Have you ever tried out something or given someone a task and they come back with something that isn’t at all what you expected, but it makes the rest of the project better?  I could give you a few examples. An intern created a simple launcher (what I asked for) but stored more parameters than he needed to (a waste of resources at the time); it saved our bacon at a conference when the loaned machines needed a different configuration. A developer created an user-defined attribute system on top of the business objects (what I asked for), but the simple lightweight system meant that most of the previous storage code could be made irrelevant. Investigating performance problems of a tagging feature led to removing a very slow, convoluted and totally useless loop in unrelated database code.  Have you ever experienced this rare, but happy, event?

This morning I was wondering if the capacity to ‘revert’ things could be applied to anything else.  I know I often depend on ‘undo’ in my word processor to stop most of my logorrhea, or at least tide it back. I make a backup of drawings before I try to color them or edit them. It lets me screw up in confidence. But there are still plenty of places where I feel like I don’t know what I’m doing or if there’s a better way of doing it, and I can’t find out because I’m afraid to screw up.  Take this WordPress platform for instance. There are a ton of options and features I have never used and might never even try, just because reverting to a state I like might be impossible.

So where else could I use recoverability?  What software packages don’t have it but would be easier to learn if they did? Can I implement recoverability with simple, generalized backups in most cases? And do I actually learn to use my stuff better if there’s no chance of messing up?  Can I apply this to everything? Can I make a team better by giving them a safety net?  If I let a dev. team self-manage and edit their bug list instead of making it my exclusive domain, would they screw up or would they learn quickly and get more efficient at it than I would alone?

Any truly Agile process needs to adapt; being able to experiment (and having the freedom to screw up from time to time) is a basic need. I think it’s important to adapt your tools, processes and thinking to learning by mistakes and being able to revert at any time.

Knowing enough to get the job and staying afloat : learning by porting

Do you have all the skills you need to change jobs? While you’re busy working with one technology or managing a project, new technologies pop up.  Even if you make an effort to stay in touch, chances are you don’t get trained for the next job; only for your current one. So even if you do have a ton of experience, you might end up starting from the bottom again.

Job offers often repeat the same patterns of required knowledge and experience. In Québec, job offers usually require you to have 2 years of experience in a specific programming language or technology for a full-time job. A position for an experienced software developer requires at least 4 years, in multiple technologies, and expert positions very often require 10 years of experience in a specific technology, even if it has not been widely used for that long.

I believe that sometimes you can replace depth of knowledge with breadth. For example, if you want to apply for a C# job without work experience in it but you have worked with Java and other OO languages, an employer could still pay attention to your resume. Can you learn enough on your own qualify for a job requiring 2 or 4 years of experience? I’m leaving out ‘expert’ level; becoming an expert is a very different process than getting to a testable level of proficiency. To become an expert you need to  spend more time ‘hacking X’ than ‘using X’. It means spending time investigating a technology, not merely using it. So the actual number of years of ‘usage’ are not as relevant as being able to show you have investigated, reported and tried to improve on various parts of a technology. If you are an expert in something, you know that you are,  and don’t need my opinion.

I’ve spent some time hiring software developers;  I know that if some of the skills are missing or incomplete, I will still consider a candidate that can demonstrate a good spread of skills, because he or she has the capacity to learn.  How fast? What is the real difference between 2 years of experience and 4?  The important thing is to be able to show competence. Can you fill in the blanks in your knowledge quickly? Can you think your way through a problem or interview question?

The difference between a craftsman and a theoretician is practice. So you need to gain experience in new technologies quickly. What is the most efficient way? You can pay for certifications and seminars, but if you’re like me you’re an autodidact who doesn’t enjoy spending thousands of dollars and weekends when all you really want is to download some software package, Google for docs and learn at your own pace and time.  What to do? Pick a problem that uses one of the technologies you want to add to your resume, and come up with a project to resolve it. Design and implement it with the new technology. When that is done, solve the same problem with another technology.  Repeat till you’re confident you can show you won’t need 3 months to get to work in a potential employer’s environment.

For example I’ve designed a method for tracking requirements. The project isn’t the important thing; identifying what technologies I want to add to my resume are what matter.  I had never used C# or .Net in a project, so once I’m done designing the architecture and database, I code it in C#.  I can learn the basics of the language and the core libraries. Once I’m happy with the results, I can start over with J2EE.  The second run in the second language is much faster since I don’t have to redesign the software & database and the design bugs have been worked out. Then I can try again in Ruby, Python, and so Forth.  For a low time cost I can add learn new skills.  It may be a bit boring, but it’s hardly redundant and wasted time.

If this is obvious or common sense it should be easy to test. I’ve actually coded the above project in C#. I’ve learned a few things specific to .Net. Setting up and learning how to configure web.config, using code-behind and file layout correctly and understanding very obscure and unhelpful error messages took the most time; figuring out the libraries, running queries and using controls was very easy using Visual Studio. I plan to reprogram the same thing using J2EE and Eclipse, I won’t have to focus at all on the design, only on learning the differences in coding and libraries.  I will note how long it takes to do the second versions and the following ones.  Who knows, I might change my thinking of how quick learning a new technology and becoming proficient with it can be much, much faster than ‘common knowledge’. Let’s not forget that most studies on this date from pre-Internet days where programmers might expect to use the same programming languages for a very long time.

I’ll post the results as soon as I have anything interesting to report.  If you have any questions or suggestions please add your comments, I am eager to hear from you!