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.

Over the years I have worked on many projects, with some successful and a great benefit to the company, and some total failures with me getting fired or otherwise leaving. What is the difference? Naturally I prefer the former and wish to avoid the latter, so I'm pondering this issue.

The key seems to be that my personal approach differs from the norm. I write code first, letting it be all spaghetti and chaos, using whatever tools "fit my hand" that I'm fluent in. I try to organize it, then give up and start over with a better design. I go through cycles, from thinking-design to coding-testing.

This may seem to be the same as any other development process, Agile or whatever, cycling between design and coding, but there does seem to be a subtle difference: The methods (ideally) followed by most teams goes design, code; design, code; ... while I'm going code, design; code, design; (if that makes any sense.)

Music analogy: some types of music have a strong downbeat while others have prominent syncopation.

In practice, I just can't think in terms of UML, specifications and so on, but grok things only by attempting to code and debug and refactor ad-hoc. I need the grounding provided by coding in order to think constructively, then to offer any opinions, advice or solutions to the team and get real work done.

In positions where I can initially hack up cowboy code without constraints of tool or language choices, I easily gain a "feel" for the data, requirements etc and eventually do good work. In formalized positions where paperwork and pure "design" comes first and only later any coding (even for small proof-of-concept projects), I am lost at sea and drown.

Therefore, I'd like to know how to either 1) change my rhythm to match the more formalized methodology-oriented team ways of doing things, or 2) find positions at organizations where my sense of development rhythm is perfect for the work.

It's probably unrealistic for a person to change their fundamental approach to things. So option 2) is preferred.

So where I can I find such positions? How common is my approach and where is it seen as viable but different, and not dismissed as undisciplined or cowboy coder ways?

share|improve this question
I'm not sure the music analogy adds much to your question, when you're talking to developers. :) –  pdr Sep 20 '12 at 20:28
Asking about the second approach will get this question closed, asking about the first approach might have people giving suggestions on how they deal with having a similar code-first approach. Personally I've been the same way but learned to ground myself by studying lots of pattern/design/problem classifications so I can immediately start breaking problems down for design without needing the code first. –  Jimmy Hoffa Sep 20 '12 at 20:28
I can't imagine working in a team the way you describe. –  Ivan Sep 20 '12 at 20:30
The music analogy is actually wrong. If you have to have a music analogy, make it "some people first improvise and then extract a composition from it, while others first construct a composition and then improvise the details". –  tdammers Sep 21 '12 at 7:06

2 Answers 2

up vote 18 down vote accepted

I used to do exactly the same thing. Then I discovered test-driven development. Far from believing that TDD is a fix-all for everyone, I do think it works for people like us, who think most naturally in code.

For me, TDD serves a number of purposes:

  1. It allows me to dive straight into coding, while I'm thinking.
  2. It allows me to design at the same time as coding.
  3. It encourages me to think about the code calling my API before designing the API itself.
  4. It encourages me to segregate code appropriately, instead of writing a long script and then thinking OO.
  5. It causes me to say "no, that can't be right," earlier in the process.
  6. It gives me freedom to refactor safely.
  7. It gives me a nice set of tests, where I used to have a disposable piece of code.
  8. It's very disciplined -- no one's accused me of being "cowboy" since I took up TDD.
  9. It's drastically improved my code.

I can't recommend it enough, if you're of that dive-in mentality.

share|improve this answer
Well stated, the design and exploration aspect of TDD is often undersold in favor of the safe refactoring aspect but is a very valuable aspect indeed. –  Turnkey Sep 20 '12 at 21:35

How common is my approach and where is it seen as viable but different, and not dismissed as undisciplined or cowboy coder ways?

Frankly, I can't think of anywhere that would think it was viable. If you cannot abstractly think about a problem without working on it, that seems like a fairly sizable flaw for a profession that works entirely on abstraction...

That said, many programmers prototype problems that they find hard to grok, or cannot answer without practical implementation and measurement. It might be that simply tailoring your first implementation as a "prototype" will help you gain acceptance within the team.

And heavily agile or startup environments will follow a "code now, refactor later" approach. As long as you're good about actually refactoring rather than "code now, code more later" then this should also fit well with your approach.

Still, I would work on being able to work through abstract design. That sort of problem solving is valuable since relatively so little of a professional programmer's time is spent writing code.

share|improve this answer
+1 I think your first paragraph is quite incorrect, however the rest of the answer is great. It's likely that the interpretation of "Design" is the point of difference. In Waterfall, design is 1000 page docs with all i's and t's dotted and crossed, never to change once code starts. In the OP's case, design might be in his head, or at best, chicken scratching's on a white board - but it is still design - somewhere in between there is a correct place for each and every project, each one different. –  mattnz Sep 21 '12 at 1:24
@mattnz - Maybe so. I consider design to be the later. If you can't even think it through or scribble something on a whiteboard... –  Telastyn Sep 21 '12 at 1:35

Your Answer


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.