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 have found this article in several posts on SO. I find myself falling into the 6th archetype; the "Theoretician".

It defines the "Theoretician" as:

The Theoretician knows everything there is to know about programming. He or she can spend four hours lecturing about the history of an obscure programming language or providing a proof of how the code you wrote is less than perfectly optimal and may take an extra three nanoseconds to run. The problem is, The Theoretician does not know a thing about software development. When The Theoretician writes code, it is so “elegant” that mere mortals cannot make sense of it. His or her favorite technique is recursion, and every block of code is tweaked to the max, at the expense of timeliness and readability.

The Theoretician is also easily distracted. A simple task that should take an hour takes Theoreticians three months, since they decide that the existing tools are not sufficient and they must build new tools to build new libraries to build a whole new system that meets their high standards. The Theoretician can be turned into one of your best players, if you can get him or her to play within the boundaries of the project itself and stop spending time working on The Ultimate Sorting Algorithm.

Even when working on what should be a simple project, I tend to get bogged don in trying to over engineer everything from scratch(This probably explains why I wasted about 2 years trying to make an operating system from scratch. But even I saw that it was pointless eventually).

What can help me to avoid doing this? And stick to KISS principles?

Thanks

share|improve this question

migrated from stackoverflow.com Apr 15 '11 at 18:21

This question came from our site for professional and enthusiast programmers.

2  
Well, the fact that you recognize the trend is a good start! –  Michael K Apr 15 '11 at 18:29
13  
I dislike how the article redefines words like "theoretician" and "elegant" just to mean "bad". –  Rein Henrichs Apr 15 '11 at 19:24
2  
Once you'll get the idea that the most intellectually challenging task is to write a really complex, brain-twisting code as simple and readable as you can, you'll get over the rest of the associated problems. –  SK-logic Apr 15 '11 at 19:28
15  
True elegance is defined by simplicity. If others can't make sense of the code, then perhaps it isn't as elegant as you think. –  Berin Loritsch Apr 15 '11 at 19:44
1  
"if you put two Code Cowboys on the same project, it is guaranteed to fail, as they trample on each other’s changes and shoot each other in the foot." — this one is brilliant :) –  Pavel Shved Apr 15 '11 at 20:17

14 Answers 14

Being a Theoretician by nature, myself, I can tell you that working in an Agile shop will quickly and decisively cure all such tendencies. In particular, an eXtreme Programming operation, with pair programming (ideally rotating frequently), test-driven development, time boxing and bounded sprints, immediately lays bare your work for all of your colleagues to see, and requires you to open up and collaborate on a minute-by-minute basis. This is an enormous shift from the separate tasks in isolated offices environment in which Theoretician-style work flourishes. It requires total honesty and total integrity, as everyone is actively depending on everyone else continuously.

I still treasure my navel-gazing, but I have to indulge it at home, or on those rare occasions when I can work on an on-the-side project that isn't part of main-line development.

share|improve this answer
    
Yes! Having another programmer to counter the theoretical tendencies works very well. –  Michael K Apr 15 '11 at 18:34
    
+1, wonderful answer. –  Carson63000 Apr 15 '11 at 22:08
    
I've been trying to apply Agile concepts to work as a lone programmer, and it works pretty well. –  Bob Murphy Apr 15 '11 at 23:21
  1. Have goals for what you're supposed to be developing.

  2. Narrow those goals to something deliverable in the near future.

  3. Then focus on those goals, eliminating all other considerations. No background. No history. No extensions. Nothing general or abstract.

  4. Then narrow them further into the very least you can do that will be deliverable. Not good. Not flexible. Not maintainable. Merely Acceptable.

  5. Then prioritize into the absolute minimum required to achieve the very least you can do. The point is to pick a date in about a week and build toward that date. If you can't deliver something in a week. Narrow. Focus. Trim. Reduce.

  6. Then eliminate the fluff. You only have a week. Keep cutting.

  7. Then focus on just a reduced implementation that will be done as early as possible. Ideally, less than a week, so you have time to write documentation.


I've worked with theoreticians. I consider the "extras" an excuse to avoid actually doing something that might be labeled a failure.

Doing -- and failing -- is hard. Talking about doing something is easier than doing something. A lot of research and thinking is a way to avoid doing the wrong thing and then reworking it after learning that the users lied.

Just put code in front of them. They'll call the code a failure. It happens. But in the process of failing you'll learn what the real requirements are. And you'll learn that they lied.

share|improve this answer
2  
Rather than -1 (which would be morally questionable for a fellow answerer), let me just say: (a) "Doing is hard?" I've pulled many all-nighters coding hard to finish my navel-gazing projects in the past, and some of them (though, indeed, not all) have actually benefitted the organizations for which I worked. Theoreticians are not (or at least not all) lazy people. (b) "Nothing general or abstract?" Really? You advocate no abstraction in the design of software? That seems pretty darned severe. (c) "Not maintainable?" REALLY??? –  Jollymorphic Apr 15 '11 at 20:11
    
@Jollymorphic: When did I say lazy? I'm making a too-subtle distinction between "Doing" and "Thinking about Doing" which may involve coding of limited value. You implied "theoretician" was a bad habit. I advocate "No Abstraction At All" as a way of breaking a habit. I advocate "Unmaintainable" as a way of breaking a habit. What you actually do is your problem. Most folks that do too much thinking continue to do a lot of thinking and indirection and abstraction even when explicitly directed not to. It's a habit. Break it by actually taking active steps to break it. –  S.Lott Apr 15 '11 at 20:35
    
Yeah I took "doing as hard" not to mean "doing is hard work, and theoreticians are too lazy to do it", but rather "doing is psychologically hard" - that it's safer and more comfortable to endlessly work (hard!) on something, than to actually nail it down and finish it. –  Carson63000 Apr 15 '11 at 22:08

I'm not sure this is such a bad thing to be. Clearly you need to be productive or you won't be doing your job, but having an interest in the field, being a student of the art, so to speak is not a bad thing.

I would play to your strengths, look for opportunities where your style and preference are an advantage.

In order to ensure you remain productive whilst indulging in writing an MVC framework in Erlang (or whatever you find interesting) you should perhaps time box your more essoteric work to, say, an hour a day. For the rest of the day just focus on the grunt work and get the job done. When you see a something interesting that would distract you bookmark it or make a note but move on, then come back to it in your alloted timeslot.

Personally I have reams of URLs they look interesting, and a pile of library books too. I perhaps get around to 10% of those URLs in the end, and maybe read 50% of the books in the end, but I still get the day job done too.

share|improve this answer

I've had this problem myself. Two techniques have helped:

  1. Use the Pomodoro technique, or some other time-management technique where you set a sequence of very short-term goals. When you have to figure out what you can accomplish in the next 25 minutes, it keeps you focused on useful work.
  2. Test-driven development. If you have to write a concrete test before you write any code, it minimizes the daydreaming. (There is no way to write a test for "elegant".) After you get something working, you may spend more time than you should refactoring it, but at least you will be working on real code rather than an imaginary ideal.

Don't beat yourself up too much. It's easier to get a Theoretician to focus and do useful work than it is to get the people-who-don't-care to expand their horizons.

share|improve this answer

Avoid stackoverflow.com. Don't get me wrong -- I'm a big fan -- but SO and other programming-oriented forums make perfect the enemy of good. After a while, you may start to feel like thousands of smart people are looking over your shoulder and nothing you write is good enough. Just get something working and try to make it understandable. You can always revisit if it needs improvement.

Also, avoid articles like the one you linked. Do you really believe that there are ten types of programmers? Or that anyone you know fits entirely into exactly one of the categories described? Articles like this one have a certain appeal because they contain a little bit of truth -- you can see yourself and/or some of your coworkers in some of the stereotypes. But the categories hold about as much water as astrological signs. Try this next time you're in at post-conference mixer: "Hi there, I'm a Code Cowboy! What's your type?"

That's not to say that your question isn't valid -- if you're overthinking things, it's good to learn how avoid that tendency. But don't let this punditry talk you into pigeonholing yourself.

share|improve this answer

There is one simple guideline which, when fully unpacked, explains in full how to avoid this scenario.

Do the simplest thing that could possibly work.

-- Kent Beck

share|improve this answer
    
Or as Einstein said: "Make everything as simple as possible, but not simpler." –  Ian Apr 15 '11 at 21:58
    
The problem is that, to a theoretician, "simple" has a lot of different meanings. Rewriting the OS kernel in Haskell using monads might strike a theoretician as the ultimate in "simplicity". –  Kristopher Johnson Apr 18 '11 at 13:10

I think one way to keep your head out of the clouds is to force yourself to write actual applications from beginning to end, in addition to writing your theoretical APIs or frameworks. Try to put a time box around something, and try to "finish" it within that time. Writing frameworks requires a good understanding of design patterns and architecture, but I've found that writing a complete application within a fixed box of time requires different skills than writing a super-well designed framework.

If you want to ever complete an application, at some point you have to bring yourself down to earth and just get it done. This may require making sacrifices on designs, or being forced to implement a feature in a way that you're not happy with, due to some type of constraint. I'm sort of like you - inclined to write and rewrite things a million times, but if I'm faced with tasks that have to be done within a certain amount of time, I find that I choose my battles, and only nitpick the most important things.

share|improve this answer

Simple :

  1. Be Pragmatic.

The opposite side of the Theorician (that have it's advantages on the information/knowledge side of the programming domain) is the Pragmatic.

To apply KISS, DRY, SOC and other way of thinking, as described in this answer, mean beeing pragmatic.

You can also learn to be pragmatic by reading this book :

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

Don't forget that theory and practice do work together, not alone. Without a lot of practice, you knowledge is nothing. Without a lot of knowledge you can't improve your practice quickly.

So, practice a lot. And learn a lot. But don't let one get over the other.

In your projects, set a deadline. Stick to it. Then think pragmatically about the way to finish your project before that deadline. (read the book, really) Then start coding, start reading what you will need to know about, switch from reading to coding and limit or your reading time.

share|improve this answer

Hrm... Perhaps maybe try getting a job in a business that requires you to write applications under a timeline. I would say for myself, that I am probably about as far away from being a theoretician as you can be, at least at work. Doing that type of work has its place and time and is important for developing yourself. However, while I appreciate that kind of ability it has no place in the business world, especially where I work. A fast-paced development environment where you're writing applications in weeks sometimes and the client wants them yesterday! I have been blessed with amazing developers and it's taken time to get everyone working as a team.

I had a guy that was about as brilliant as can be, but like you, always had to squeeze the last little bit out of his code even when it was working fine, even to the point where he started writing custom controls that were essentially the same as the ones provided by the environment. It was all very cool but such a waste of time when we had to get stuff out on time. Often times these side projects backed the team up and eventually he started to feel the pressure from the others and he shaped up. I would suggest to start working in a team environment with some other good developers that have to push products out. There is always time later to refactor and redo things or write the most kick-ass MergeSort ever; but sometimes you have to get the product to a point where it's working and get it out to the client. To reward yourself for your new programming zen you can go home and rock out a new Linux distro!

share|improve this answer

There is nothing wrong with being a 'theoretician' in the usual sense of the word. Having background knowledge and being able to understand the latest CS research is a great ability to have, as it is a gold mine of good and original ideas.

The 'real question' here is more apparent in the later half of the post. Know the specific project goal and work toward that end, not any other end. It's really just a matter of self-discipline in this case. See S. Lott's answer for more on this :).

share|improve this answer

Refocus your mind from programming and even accomplishing things to delivering working software. It sets right your priorities.

How to achieve this is another story. The best way is to conceive some project and go through all the steps to launch it into production. After that you'll have a different mindset than before.

share|improve this answer

Thanx for this post. It makes my work even more worth while. I feel the same having an education in Information Architecture working as a Software Developer. Often I find myself struggling with "where to change things" rather than "what to change". There are too many relations, too many smart and generic stuff around that it takes too long to find out how the stuff works.

So I start to ask questions, and even more questions until I get to know HOW and WHERE this is really built. And let me tell you - it works. The more questions a fire, the less important it is to keep up the original architecture, and finally where back to the basics

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}
share|improve this answer

Ask your boss to get a mentor, and then do as the mentor says.

The hard part is keeping focus, and recognizing that "hey, let's rewrite the operating system" will not benefit substantially towards finishing the task you've been given (which is why a project manager will not do).

Also have the mentor review ALL your designs before coding, and the actual code after coding. This will help you keep focus on what needs to be done.

share|improve this answer

I have the same temptation to over-engineer things, and it takes self-discipline and organization to get past it. When coding for somebody else, here's how I do it:

  1. When starting a discrete task, spend a few minutes thinking about what's really required as far as functionality, quality, delivery date, etc.
  2. Take some more time to plan how to do that, breaking it down into sub-tasks, sub-sub-tasks, etc., keeping the code's customer's goals in mind.
  3. Estimate the time for each item, adding up to 50% for unknowns. If an item will take more than four hours, break it down some more. (If I were doing college projects, I'd use a spreadsheet, but as a consultant with multiple clients, I use an issue-tracking system called Redmine.)
  4. Most importantly: do only the items I came up with.

Of course, stuff happens. Sometimes I find I need to do more things - so I start over at #1. Sometimes I find a task will take much longer than I thought - start over at #1. Sometimes I know in advance my design will need more details later - so I plan a re-estimation subtask where I start over at #1.

The more I do this, the better I get at it. Self-discipline is a mental muscle that strengthens with exercise, and I also improve at estimating how long things will take and making technical trade-offs. And I find it helpful to remember a quote from General Patton: "A good plan violently executed now is better than a perfect plan executed next week."

As a lone developer, my workflow combines this with aspects of Agile, including a Kanban board. I sometimes go off on tangents, but I try to limit deviations to a few hours a week, and it works pretty well.

If you plan to work in private industry, it's really important to control the "theoretician" impulse. The most brilliant programmer I know lives in Silicon Valley, but hasn't had a job for years because he has such a reputation for delivering perfect code far too late.

share|improve this answer

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.