Developing at the speed of thought

Well is that a quote from “Business @ The Speed of thought” for bill gates. He could easily sue you for this one. He is the son of a lawyer remember. And he is Bill Gates . It’s a great book by the way, even if a bit old. Advise you to read it.

You point is a good one here. I remember seeing the two extremes. Some people squeezed a large program into 200 lines of code, making it so non-modifiable. I still wonder how they did it. It was an achievement, but non-worthy one. Others, and especially in the Java project when we had to simulate elevator using GUI, have done it all wrong and encapsulated all environment into 3 classes only! Why 3, I dunno.

I also remember the funny professor (who loved long function names I told you about) who gave us C assignment. I managed to get it nice DRY and clean. Next assignment was to modify few things in it, and explain the new pseudocode we followed. When I turned it in, I only had to change 5 lines of code or so. It was clear evidence for me, Pheww planning ahead made life easy. Only until I got my low grade on the assignment as Dr. was not convinced I could run it like this ;/. He didn’t ask for the code, and he didn’t believe me. It’s sometimes like discussing philosophy rather than running the program to prove it!

But your first paragraph also lets me think larger. Not only develop, but people work and live at the speed of thought. They juts go full speed, doing multi-tasking, pushing every wheel an inch every once in a while. I tend to believe this is wrong. Some multi-tasking is required. Some rushing at times is needed. But you must also take a break, step back a bet and look at the big picture you are drawing. Am I moving in the right direction? Is this what I want in the end? Is there a better way for it?

It’s usually useful after long hard work to free your mind, think again about what you did, how long it took you, was there a better way to do it, should you continue doing it or not. Otherwise, it’s your left side of the brain that is mostly working, not giving any chance for the right side to influence and innovate further. I worked with a great super kind of guy who is always on the move, coming up with new ideas and stuff. He is really great person to work with. But then when you want to do business with him, you notice he is simply juggling too many balls and he may not have the time to properly understand your idea or concern. He simply rushes at times when he feels things are slow, without understanding why it’s slow or not moving. It simply needed more planning and requirement specifications. Net result is, either things stop or run into the wrong direction.

Reply to comment

Bashar – wow, that comment is like a post of its own!

You keep on mentioning that professor of yours, and I’m bewildered each time. In my current CS course, I was looking over the marking scheme for the assignments, and having the methods be less than 25 lines of code is an actual requirement! Well, I guess there’s a certain level of luck involved with the professors one gets.

And you’re absolutely right – same could be applied outside of coding, to the real life. One can’t always act on the first instinct alone. As rational beings, it is simply expected to exercise a certain level of thought for making decisions.

Reply to comment

I am not a programmer but I came to read some of the things you mention and clean code is something many strive for. I have started working on a cleaner HTML coding, even if it’s far less important than the “real thing’ you guys do here

Excellent blog. I have bookmarked it and will try to come often. There are many things I can learn from this

Reply to comment

Don’t be fooled; Tony doesn’t do any real work.

Reply to comment

As someone who does competitive programming a lot, I would have to say that I completely agree with this. When I’m writing a solution to a problem, I try to spend a lot of time thinking every detail of the program through. The more you think, the less time you’ll spend coding and debugging. And you’ll probably get the problem correct, too. I would like to give as an example something that happened a couple of days ago. I was participating in a practice session for the ACM International Collegiate Programming Contest Waterloo team. One of my team mates was coding a solution to a problem. He thought about it for some time and then started solving it. He spent an hour trying to get it to work, but it didn’t. The practice ended and his solution didn’t work. 5 minutes after the practice, he says: “Now that I think about it, there’s a really simple solution to this problem!” (Paraphrased). Using his idea, I was able to code that solution up in 5 minutes and it worked.

Reply to comment

Dojo – I assure you that there are “real things” done, that are far less important than valid XHTML wtd brings up an interesting point!

Konstantin – such things happen surprisingly often. I’ve gotten myself into a habit of asking if I’m pursuing the right design, if whatever I’m working on is taking considerably longer than it should be.

One shouldn’t get too attached to the code written – I delete as much code as I write. Rather than spending another hour figuring out the complicated solution, it’s a better idea to throw out that code, start from scratch, and following Konstantin’s example – implement a new working solution in 5 minutes!

Reply to comment

Tony: You can tell how much I loved that professor

Reply to comment

that is so true…. when i first started programming i remember creating a tower defense game and about 100 lines of it were checking to see if the tower hit the enemey which could have been compressed into one for loop

every now and then i find my self repeating code but i usually end up deleting that and making it more efficiant

great blog Tony

Reply to comment

thx momop!

efficiency is not as important here, as clean code and solid design. I’ll take nicer looking code, over a slightly faster mess any day. Though I suspect that you have meant that as well.

Reply to comment

Hi tony,
First i’m disagree with your post about ruby as better language than java.I’ll let you know about that later.

Thining fast for clean coding requires much pateince.One of my good friend told me that instead of thinking too much into complex things,think simple and try and create programs,that makes you better developer.This is true when you do some java swing prorams,how you add component one by one and then you think about the event handling but if you think for event handling much before the component design,most developers get confuse.WHile some vetereans can hold their breathe here.
If this thinking terminology is for new programmers then simple visualisation,clean code and patience is the way to go.As new programmers you have to reinvent wheels so many times to develop the logic.You know we used to write prime numbers and fibbonaci or quinne programs in almost every programming language that we touch.

Cheers Mahesh

Reply to comment

@Onecore — I haven’t even mentioned Ruby in this post! Though I’ll be awaiting your follow-up on the merits of Java.

Reply to comment

now that someone mentioned ruby, i must say anyone who ever compares a language like perl-ruby-python to java-c-c compares totally different use cases.

even perl, but a lot more so python and ruby, make a task at hand a lot shorter than ANY of the other languages. java is just notorically mentioned because it was hyped and pushed a lot.

but actually, since someone DID compare ruby to java, i am curious how java is better than ruby in regards to solving a given NEW problem at hand if time is short.

Reply to comment

For hard problems I always find myself:

1. Thinking
2. Coding it in Haskell
3. Rewriting it in whatever language I was supposed to use

Haskell’s very succinct and the exercise of writing it down in a programming language reveals the things I’ve skimmed over.

However that does not mean there aren’t many tasks in large project that are sheer gruntwork: moving piles of dirt from one place to another. That’s the unavoidable consequence of any large body of work (programs, books, or buildings for that matter).

Reply to comment

This is something I try to push on the developers I work with.
I work in the mobile phone area and we often have very little memory or CPU power to play around with.
Writing small, tight, and modular code is so very critical here and sometimes we get new coders from the desktop/server/Java space. Often, in these instances, we have to basically retrain them to think about their code more carefully.
When an engineer comes back to me with a module that he wrote in 1 or 2 days I do a very brief review and usually have to send him back to tighten the code, simply because they didn’t think about the solution, but rather just started typing.
Sometimes they get upset about this at first, but once they get the hang of it they get very excited about the cool and clean solutions they come up with.
It teaches them to write code they can be proud of and brag about.
And I let them. It’s an important and valuable skill.

Reply to comment

Developement is not architecting. You don’t put together a blueprint and then piece together a perfect replica that works exactly the way you want it.

If person A gets it working within the first hour, isn’t completely happy with it, and refactors it until it has the flexibility and/or performance that he’s after, how is that worse than a guy who stares at a monitor for 2-2.5 hours and then flops it down?

Give me the conscientious developer any day of the week.

Reply to comment

Refactoring in an hour is fine. It’s grunting for 3 hours without the thought to refactor or change direction, that’s a problem. In the extreme examples considered for the article, the students completely lack the concepts of flexibility and performance, and simply bruteforce towards a “working” solution with more lines of code.

Reply to comment

I guess the problems I work on aren’t “computer sciency” enough.

80% or more (probably 95% ) of programming done in the wild does not nearly need to be thought about for 1 hour, let alone 3. But I’m surely biased as webapps do not tend to be all that complex usually (what I work on).

If someone did hard CS problem coding day in and day out, they might assume much of the rest of the world did as well.

Reply to comment

I disagree Will Johnson. Web apps are very complex, as they are essentially a distributed system, which implies all sorts of critical issues which have to be properly balanced. Issues such as latency, security (replay attacks, access control, etc.), robustness (fail over, availability, etc.), parallelism, data and code migration, and so on. It’s just that the space “modern” web apps cut out is a very small piece of the space of possible web programs, simply because most web frameworks are so limited and unsafe. See the web-calculus for a idea of the hidden potential that web apps can fulfill. The web-calculus handles just about all of the above issues in a Java server environment.

Reply to comment

The quality of the thinking in those 3 hours has to be of a certain quality for this advice to have any merit. I don’t think it is as simple as saying if you think more, you will spend less time coding. Without talking about that thought and analysis process to follow, you may very we’ll just see students spend more time thinking, but no less time coding.

Reply to comment

Heh, I guess that’s why I dropped out during the first year of my BSc. I’m definitely a “code now, structure later” type of coder.

In fact, I tend to write programs the way I write stories. First comes the rough draft, then comes the first re-write, THEN I design the structure and layout, then comes the second re-write.

Then I start thinking about trimming down my code.

It may not be efficient, but it’s fun!

Reply to comment

In reference to the first post in this comment thread I wrote a piece on taking time off what you are doing to step back and innovate. Might be an interesting read for some folk.

http://ponderousprog.blogspot.com/2007/11/taking-time-out-pause-innovates.html

Reply to comment

“IIf you ever catch yourself copying a part of your code to paste it elsewhere in your application – stop. Refactor. Step back and think about your design.“

While I think DRY is a Good Thing, I don’t think immediate refactoring is necessarily good. The danger is that the two things turn out to be not quite the same, and then you have to introduce some conditionals, and you end up spending more time making your abstraction work than making your program work. I think it’s better to copy the code and only refactor once you know it works. Premature refactoring can lead to wonky abstractions.

Reply to comment

[...] then typing. Guilty as charged: If you are spending more time writing code, than thinking about what code you should write – you [...]

It depends upon one’s ability to think, of course, but generally one should spend more time thinking than typing.

The director of operations, at a company where I once worked as an engineer, went to the VP, Engineering and said, “Every time I walk past David’s office, he has his feet on the desk and his hands laced behind his head.” The VP said, “Good, that’s when he’s doing his best work.”

Reply to comment

@David – that’s really cool that a VP really understands what you are doing.

Developing software is a lot of mental labour, which is difficult for people outside the field to understand. After completing a task I’ve set out for myself, I like to go out for short walks — get some fresh air, relax my eyes, refresh the mind. 5 minutes out does absolute wonders. Actually if I’m stuck at a problem, same also helps to think from a new perspective.

Though back when I was working for a not-so-technical department at a University, they were pretty strict about such things. I was supposed to be on the clock and in the cubicle 9 to 5, actual results came second. Naturally I’ve made a decision to never come back to such kind of establishments, they are completely missing the point of what they are hiring developers for.

Reply to comment

4600 lines ! How the hell did they manage to write 4600 lines that does nothing but create Sudoku puzzles. I just had a quick look through the Sudoku solver that I wrote a while back and it comes in at 382 lines. That includes all the HTML and display code. Modifying it so that it creates new puzzles would only add 20 or so lines… and creating the new puzzles EFFECIENTLY would only take about 40 or 50.
I keep meaning to add those 40 or 50 lines but it requires so much THINKING before hand that I never have enough time in one stretch to do it.

That said, I do occasionally find myself spending more time coding than thinking. Or, more accurately, more time debugging than thinking. The reason for this is mostly due to inexperience with the language in question. Being a Sysadmin now, rather than a dedicated coder, I tend to switch from Perl to PHP to bash to C to C to Java depending on what is needed. Frequently, the language that is most appropriate is one that I haven’t used before or haven’t used for a long time. Most of the programs I write these days are exceedingly simple and don’t require all that much thought anyway. I also tend to have to debug other people’s code when they put it on the live server and it breaks everything. I don’t get the luxury of “thinking time”… I have the CEO or my line manager on my back asking when things will be working again.

There’s a great book called “The Pragmatic Programmer” that discusses a lot of this stuff. They mention the “DRY” principle and go into detail about many other things that affect real-world coding. Definitely worth a read.

Reply to comment

Aaaaiiiieeee ! I just read through all 4600 lines of that Sudoku program. I now understand how he managed to get so many lines. Loop ? What’s a loop ?

This function could well be submitted as a CSOTD to worsethanfailure.com:

//unique solution number

public static long solutionTime ()

{

long enterMilliSec = System.currentTimeMillis ();

long checkMilliSec = System.currentTimeMillis ();

checkMilliSec = System.currentTimeMillis ();

return checkMilliSec;

}

Not only is it not unique (Hello “race condition”) but checkMilliSec is assigned twice and enterMilleSec isn’t even used. It’s a good thing Java has garbage collection.

Several of the methods he HAS written could be replaced by a single line. Also, the convertToString() method should be called toString().

Reply to comment