Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I find that I have to learn new technologies fairly regularly as a contractor in order to keep competitive.

However, I also find that (not only, but especially) in these circumstances, I tend to end up with really bad code flow and need to do a lot of rework in order to achieve a canonical solution.

While I realise that there are those contract programmers out there have no problems with taking the money and running, I wish to maintain good relationships through a good codebase that is not only easy, but fun to maintain -- which ultimately translates into a more lucrative business for me in the long run, as architectural risks are kept minimal.

However, I wonder if there are ways by which I could improve my ability to learn technologies while at the same time getting structure closer to what is correct / canon, right from the start -- particularly given some poorly documented techs, or those that are documented in a fragmentary fashion. While there is no substitute for experience, I want to streamline this process, reducing the considerable refactoring time I suffer at present, as it is something I experience often.

share|improve this question
    
I have yet to find a code that is fun to maintain T_T –  Songo Sep 24 '13 at 12:03
1  
If you ever manage to find a way to lower the amount of refactoring you do ... please let me know! :) –  Simon Whitehead Sep 24 '13 at 12:28

5 Answers 5

I think there are two approaches that might help.

First, don't write ''final'' code while learning. I think there's no reason you couldn't write some small programs for testing the features that lack documentation or you didn't understand yet.

Also, you should write tests that check for the behaviour you would expect. In case you misunderstood something, you realise it fast and can change without breaking much.

share|improve this answer

"Taking the money and running" isn't always an M.O. of the contractor - in previous experience, some of my clients have been "one and done" -- they want a quick solution and don't require constant upkeep. Some have come back for enhancements, others never needed my services again (which I take as a complement, meaning that what I provided was stable).

Refactoring is a natural aspect of the programming discipline; especially if you're on a retainer or maintain the lineage of a true product. I wouldn't be afraid of it, as long as when you refactor, it's based on functional need, not cosmetic desire.

In terms of picking up new languages quickly, I've always found micro-examples to serve quite well. E.g. "ruby flow control", "python iteration", or "php introspection" typically get me results within 1-2 clicks. Next time you're writing something in a language in which you're comfortable, take a second to mimic that construct in another language using a micro-example found via web search.

...and bookmarks. Lots and lots of bookmarks ;)

share|improve this answer

I wish to maintain good relationships through a good codebase that is not only easy, but fun to maintain...

I'm not sure if 'fun' was just a poor word choice, or you genuinely meant 'fun', but let me be clear - 'Fun' should 'never' be part of the equation. Your employer is paying you to write business code. It should work and it should be maintainable. You aren't writing code for its own sake or for your own amusement.

-- which ultimately translates into a more lucrative business for me in the long run, as architectural risks are kept minimal.

It's true - Gaining a command over the latest and greatest technologies will strengthen your resume and increase your earning potential. But remember - These new, shiny technologies are supposed to solve a problem.

That is they're either supposed to

  • Reduce development time and keep architectural risks constant.
  • Reduce architectural risks and keep development time constant.
  • Or both.

If your new technology doesn't do any of the above three, then you shouldn't use it. Period.

However, I wonder if there are ways by which I could improve my ability to learn technologies while at the same time getting structure closer to what is correct / canon, right from the start -- particularly given some poorly documented techs, or those that are documented in a fragmentary fashion. While there is no substitute for experience, I want to streamline this process, reducing the considerable refactoring time I suffer at present, as it is something I experience often.

Hmm... Well you're getting to the core of the problem - "There is no substitute for experience."

So with that being said, let me offer you some advice:

  • You should spend all of your energy trying to produce clean, working code. (If you're doing Objected Oriented programming, try to follow the SOLID principles.)
  • When you're working with new technologies, it may feel like your taking the "scenic" route sometimes, and you're code might not be perfect right away.
    • That's OK. That's normal. Speed kills. "The only way to go fast is to go well."
  • Take baby steps. When working with a new and unfamiliar technology, break your programming task down into steps so small that it feels like you're writing 'Hello World'.
    • And if you run into a roadblock with your new technology, consider that your steps may be too big:

When you find yourself in this position:

  1. Get your code working first.
  2. Understand why it works (even if you have to spend additional time reading sparse documentation and querying Stack Overflow).
  3. Then clean it up.
  4. Then write some tests to confirm that it works.
  5. Repeat any combination of Steps #1-4 if necessary.
  6. Then make a final commit and move on to your next task.
share|improve this answer
1  
OP is game developer (according to profile), so a lot of fun is part of the equation. –  Roman Susi Sep 24 '13 at 18:13
    
Fun is probably not the right word, but code should not be the opposite of fun to maintain. Maybe enjoyable is a better word, in the sense that "most code is annoying to maintain, this is fun by comparison." –  Snowman Sep 25 '13 at 1:15
    
@RomanSusi: reddit.com/r/programming/comments/1njh7f/… –  Jim G. Oct 2 '13 at 13:45
1  
It's still a matter of taste and right workplace. If it is not fun for OP, I guess, he would seek a way quit. Asking questions tells he still cares about what he is doing. –  Roman Susi Oct 2 '13 at 16:29
    
@JimG., Why develop if you do not enjoy what you do, and if you cannot introduce better practices where things are clearly a slog? I do not see inefficiencies as inevitable. As a mid 30's, long-time freelance dev working in games, mobile and web (the latter two to make a living, the former because it has always been my passion), not a "young developer" as you snidely suggest, I question because I choose to improve. I did not upvote your answer because you assume too much. Know your audience before assuming age / experience; my gamedev SE profile is considerably higher ranked than your SO one. –  Nick Wiggill Jan 22 at 9:38

The picture is not black and white with respect to "new" and "better" technologies. They do not come abruptly. The most efficient approach is to be a little bit lazy and learn technologies when they will become inevitable and reach some critical mass. I am talking about technologies you need to integrate with (to stay competitive) - it's just one side. The rest of the answer talk about the implementation-side technologies, where you have a choice.

Choose technologies on the basis of solving most painful problems first. I am not sure what does it mean canonical versus non-canonical in your question, I think concrete techical solution always solve concrete technical problem.

As a word of warning, I have found it not cost effective to inculcate "newer" approaches to "older" systems. Unless there are some really nasty problems, newer, "next version" technologies make development unnecessary costlier.

Unless absolutely necessary, learning completely new things is better done with toy projects or throw-away prototypes. Working on a new programming project always includes some learning, so a balance should be found (including "fun" into equation - motivational factor for both programming and maintaining).

Getting something right from the start requires experience and thus experiments. For some new domain a prototype, proof-of-concept, etc may be needed first. Product's life cycle needs to be roughly estimated, as well as possible "points of grow". For example, if you are about to hard-code French into the code, and you are vaguely aware that the client is planning to come to US market next year, then include i18n/l10n from the start. Same with Unicode support, timezones, and whatever may be applicable in your case. Yes, it is hard to predict the development of the system, and may be double hard to do it using unknown technology, but if the foundation is right (i.e. architectural decision is not a short-cutting compromise), solution will survive changes in the requirements and future adaptations. Familiarize youself with the problem domain. Solutions tend to naturally evolve (converge) into areas of problem domain (already known). For example, if the customer sells hamburgers, it could be beneficial to make a more general solution, which does not exclude pizzas. In many cases small generalization of the problem (in directions guided by knowing problem domain a bit wider) helps keep solution simpler and does not affect development time negatively at all.

Learn by example: It's very rare situation when you are early adopter of something. And do not include too many new technologies into solution (if possible).

Also, if you do not like refactoring, choose less agile process. Use more time to analize problem and design solution.

share|improve this answer

The best way to learn something is to have a good teacher. They will filter the vast amount of information down to what is important and continue to help you gain a deeper understanding. The good ones will also altert the intstructions as they go along to meet your immediate needs.

This doesn't mean you have to find and pay for a formal software instructor. Find someone that is willing to mentor you. Possibly you could crosss-train each other. There are other consultants out there that have a client needing a language they don't fully understand who could use your help as well.

Personally, this is one of the biggest problems I've faced in my career. The few positions I've held that had people who could stretch my skills were invaluable. I wish there were more. Too many young devs take positions where they work alone.

share|improve this answer
    
Not sure why someone else chose to downvote this, I actually think it's a very good answer, even if it is only part of the bigger picture. Thanks Jeff. –  Nick Wiggill Sep 24 '13 at 18:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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