How do you learn a new platform/toolkit while producing working code and keeping your codebase clean?

When I know what I can do with the underlying platform and toolkit, I usually do this:

  1. I create a new branch (with GIT, in my case)
  2. I write a few unit tests (with JUnit, for example)
  3. I write my code until it passes my tests

So far, so good. The problem is that very often I do not know what I can do with the toolkit because it is brand new to me. I work as a consulant so I cannot have my preferred language/platform/toolkit. I have to cope with whatever the customer uses for the task at hand.

Most often, I have to deal (often in a hurry) with a large toolkit that I know very little so I'm forced to "learn by doing" (actually, programming by "trial and error") and this makes me anxious.

Please note that, at some point in the learning process, usually I already have:

  1. read one or more five-stars books
  2. followed one or more web tutorials (writing working code a line at a time)
  3. created a couple of small experimental projects with my IDE (IntelliJ IDEA, at the moment. I use Eclipse, Netbeans and others, as well.)

Despite all my efforts, at this point usually I can just have a coarse understanding of the platform/toolkit I have to use. I cannot yet grasp each and every detail. This means that each and every new feature that involves some data preparation and some non-trivial algorithm is a pain to implement and requires a lot of trial-and-error.

Unfortunately, working by trial-and-error is neither safe nor easy. Actually, this is the phase that makes me most anxious: experimenting with a new toolkit while producing working code and keeping my codebase clean.

Usually, at this stage I cannot use the Eclipse Scrapbook because the code I have to write is already too large and complex for this small tool. In the same way, I cannot use any more an indipendent small project for my experiments because I need to try the new code in place. I can just write my code in place and rely on GIT for a safe bail-out. This makes me anxious because this kind of intertwined, half-ripe code can rapidly become incredibly hard to manage.

How do you face this phase of the development process?

How do you learn-by-doing without making a mess of your codebase?

Any tips&tricks, best practice or something like that?

  • Step 1: Figure out what the client wants. Step 2: Go learn how to do it. That's pretty much the extend of my preparation. Its impossible to know everything, so I usually don't even try. The best I can do is be reasonably certain I'm not doing something totally stupid (Google helps me with that), and make whatever I'm adding completely separate and in its own module if possible so it can be easily removed at a later date by someone (more than likely me) trying to optimize the system. :) – Rachel Nov 21 '12 at 19:47
  • I always thought that the practice of creating tests first and then code that passes them misses the point of TDD and Agile. It's a tad bit too extreme for me, but maybe it's just me. – DPM Nov 21 '12 at 19:55
  • @Rachel. Separating concerns is a very good approach, of course, and I would be happy to discover some new way to use it (put aside the well-known OOP practices). For example, would you suggest some AOP (Aspects-Oriented) trick to keep my new code separated from the existing one? I mean, pushing AOP beyond its usual application field. – AlexBottoni Nov 22 '12 at 8:24

I find the best solution is to not learn by doing in that way.

Rather than immediately trying to solve your problem, isolate what you don't understand and figure that out first.

Take a trivial example, you don't know how Nullable works in the .NET framework. Rather than attempting to write code using it, create a sample application and play around with it.

For example:

public static void Main(string[] args)
    var test = new int?();
    Console.WriteLine("new int? - {0}", test);
    test = 0;
    Console.WriteLine("0 - {0}", test);
    test = 1;
    Console.WriteLine("1 - {0}", test);
    test = null;
    Console.WriteLine("null - {0}", test);

    Console.WriteLine("test == null - {0}", test == null);
    Console.WriteLine("test.HasValue - {0}", test.HasValue);
    Console.WriteLine("test.GetValueOrDefault() - {0}", test.GetValueOrDefault());
    Console.WriteLine("test.GetValueOrDefault(2) - {0}", test.GetValueOrDefault(2));

Throwing in any examples you find and seeing what happens. This allows you to perform the unit testing style of exploration you are used to without having to run a complex code base through your tools.

Note that this can sometimes work with existing code bases. Be careful of assumptions about the running environment however. If you call a DLL that expects to be running in an IIS environment from an EXE you may run into some odd errors.

  • I do this. The problem is: what happens when you have already tried all what can be tried in a separated project and now you have to put your code in place and see how it works in its natural context? How to avoid the usual mess produced by your (unavoidable) lack of experience? Is there any parachute you can use in these cases (put aside a GIT branch)? – AlexBottoni Nov 22 '12 at 8:02

Assuming you have read some books and documentation, the only way to go forward from there is to practice. You are lucky in that when you are a consultant that you already have a project that needs doing, so you can just start doing it.

In general, I think your current approach is correct.


a) Learn the background and the theory.

b) Create tests fot TDD.

c) Start working.

The only thing I would add is

d) Refactor when you learn/discover a better way of doing something that you've already done.

The above is IMHO always the right approach to new frameworks. You can't expect to read books and docs until you know EVERYTHING and only then start coding. The human mind doesn't work like that, and even if it did that would probably be sub-optimal.


Well I'm by no means a pro, but I learn as the process goes on, learning and implementing new features as they're needed, however I have the luxuries of time and being a student.

As far as I can tell, you're doing a pretty good job of keeping up with all the changes.

The only tip I can give as a beginner is to break it down into consumable bits, and learn the features you need side by side with the basics of the toolkit/platform so that you can code the trivial code faster and be satisfied with your overall code.


I was going to suggest that you make a throwaway project to familiarize yourself with the tool but you've already got that covered. There will always be more the to tool than books, tutorials, and sample projects can show you. All the nuances come out only with experience. But if you don't feel you have a sufficient grasp on a tool, I'd simply spend more time on those three steps.

You plan seems solid to me.

I work as a consulant

Oh. Well, in that case, FAKE IT. Deliver whatever you can slap together in a roughshod manner that appears to work, bill the customer for meeting your contractual obligation, and leave. If it's not the prettiest, that's someone else's problem. Or it's seeding for future employment. Thus is the life of a contractor. If you have specific domain knowledge about whatever, be sure to fork that over in a handy document or tool or example code, as that's what they're really paying you for. But if they just need a code-monkey for a weekend, and they don't let you use the tools you know, then this is the sort of results they should expect. Sorry, but that's how piece-meal work turns out. If you put in that extra effort, another consultant will undercut you. If your client was hiring for quality, they'd have actually HIRED someone.

Don't get me wrong, consultants can be a god-send when you need a superman of SQL or a gnu guru to banish the bugs that plague you. But hiring a consultant who has to learn the tools? naw.

  • "Consultant" is one of those ennobled word we use in Italy to hide the crude reality. "Being a consultant" consist mainly in working as a slave for a handful of coins. No real consulting is actually performed and no technical skill is actually required. As all of my collegues, I try to do my best just because I love this job. :-) – AlexBottoni Nov 21 '12 at 20:13
  • Ah. I was not aware of the regional differences with the term. Sad to hear your plight. – Philip Nov 21 '12 at 20:27
  • I do not think this answer should be downvoted. Even if it is sarcastic in its last part, it raises a point that I (we) cannot ignore: consulting (contracting) actually calls for a quick&dirty approach. – AlexBottoni Nov 22 '12 at 7:55
  • Regarding the throwaway projects: I usually make one of them when time permits. Actually, many of my small experimental projects can be seen as throwaway projects. Despite this, I tend to avoid this approach because, too often, my quick&dirty throwaway project is adopted as the "finished" product by the customer (making maintenance a real nightmare). – AlexBottoni Nov 22 '12 at 8:12
  • @AlexBottoni Consulting does not call for a quick and dirty approach if you want to maintain a reputation and long-term business relationships. Quite the opposite, hacking crap together so that people hate your guts when you leave will eventually backfire. This is a near-sighted approach. The world is only getting smaller. – MrFox Nov 29 '12 at 19:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.