Avoid becomming a "Theoretician" programmer

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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.

Answer 9

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!

Answer 10

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 :).

Answer 11

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.

Answer 12

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!");
}

Answer 13

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.

Answer 14

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.