My workflow has always been to write one logical step and then run the program and inspect the output. This process have served me incredibly well for assignments in university. However, as I do more development, there are often times when simply compiling and running your code takes 1 to 2 minutes. Examples include uploading a program to a microcontroller, requiring interaction with an external server, and unable to implement automation due to authentication, software architecture, or complexity.

These types of tasks are very unsuitable to how I usually program, and I'm having difficulties coding effectively. I usually make a lot of syntax errors and logic errors, most of which I easily catch by testing. However, with such a long wait time, this method is too time consuming.

  • Are you using an IDE?
    – Woot4Moo
    Commented Jun 9, 2011 at 14:22
  • 3
    Your root problem isn't being unable to code effectively, it's tests that take too long to run. You're asking the wrong question. Commented Jun 9, 2011 at 19:39
  • Use a language that has a REPL. Commented Jun 13, 2011 at 20:31
  • Do you have colleagues that you can ask and learn from?
    – user985366
    Commented Sep 29, 2017 at 22:21

8 Answers 8


First off, any sort of interactive debugging is great. You want that in your toolkit, because if not yet, then someday you will really benefit from having it. (Details vary by language, platform, and IDE.)

requiring interaction with an external server, and unable to implement automation due to authentication, software architecture, or complexity.

I'd look into some frameworks for using mock objects. These allow you to surround the component being tested with a fake ecosystem of other components, so that your tests are more specifically-targeted and you can avoid testing everything as a whole unit as much.

In addition, the mock objects themselves can be programmed in with assertions, so you can check that the component-being-tested really did make a certain call.


I would work hard to reduce the test time. I had worked in a couple of companies developing embedded code, and testing was painful, requiring trips to the server room and manual FTPs and reboots and multiple commands to the test hardware. Then I joined a really good group, where I could simply type 'make test' at my desk and get results back in under a minute. In that one minute:

  • My code was built into a new kernel image for embedded hardware.
  • The DHCP server was updated to point to the new kernel.
  • The test board was rebooted.
  • The test board retrieved the kernel from my workstation via an NFS mount.
  • The test board rebooted to the new kernel.
  • The unit tests were run.
  • The unit test output was delivered back to my workstation.

It took some time to get all this working, but the effort to automate all these steps was recouped a hundredfold as the development staff grew.

  • 2
    +1. There is no problem that cannot be solved with a sufficient amount of shell script. Commented Jun 9, 2011 at 14:19
  • 1
    I won't stay in teams that don't care about improving velocity. Commented Jun 9, 2011 at 15:23
  • @Tom Except too many layers of abst--er, shell scripts ;)
    – Darien
    Commented Jun 9, 2011 at 17:37
  • Nah, you just write a shell script which wraps the other shell script. Then there's just that one shell script. TRUST ME. Commented Jun 10, 2011 at 8:55
  • 3
    +1: Improving the velocity of edit -> compile -> load -> run -> debug -> edit is the single best thing you can do to speed code production. When I worked at Tymshare we had a guy who claimed (correctly) that his code ran correctly on the first try 87% of the time. I, on the other hand, coded like I was overdosed on caffeine monkey at 1am (which I was). I made a ton of typo errors, etc., but I didn't worry about them because I knew the compiler would catch them. At the end of the day I was probably 3 to 5 times more productive than he was. Commented Jun 10, 2011 at 19:33

Automated tests are not replacement for review and understanding.

It may be that you are using testing as a crutch. If you are doing this you will impede your learning. I am not advocating you don't test. Instead I would recommend you that before you run your test review what you wrote. Understand what you wrote, make sure it makes sense and make sure the syntax looks correct.


You already gave the answer: I usually make a lot of syntax errors and logic errors

So working hard on improving that, you should be able to reduce the time on testing. The syntax errors should be the very first you should reduce. Never had a programming test with a paper and a pencil in your study?

I had the same thing when I switched from PHP to Java. I had to learn to debug instead of just printing some variables and press F5 in the browser...

  • 2
    We all make stupid mistakes from time to time, they only occur less with time and experience.
    – maple_shaft
    Commented Jun 8, 2011 at 18:41
  • @maple_shaft thats true, but when he says make a lot of it sounds like he should invest his energy to improve it Commented Jun 8, 2011 at 18:57
  • 3
    I did a fair amount of coding on paper and on whiteboards. The problem is the same: the code looks right on the first inspection, but after running it, you notice your mistakes. Commented Jun 8, 2011 at 19:10
  • noting mistakes in code and writing code with wrong syntax is a big difference. The first one can happen to everybody, the second one suggest beginner level. I do not know your background, but even as a beginner you should minimize syntax issues. Whats your IDE and language? It should support syntax checks. Commented Jun 8, 2011 at 19:21
  • @Anne Nonimus: Do you mean logical errors? Syntax errors should be picked up by your IDE (ideally - if you are working with code that's dynamically generated then those syntax errors will not get picked up at compile time). Commented Jun 8, 2011 at 19:24

You need a good Unit or Functional test platform that can automatically run tests for you, preferably in the background. This will require the use of Mocks as noted above and depending on the language you are using some sort of dependency injection.

By making your objects as independent as possible and then using injection methods to add outside constraints it is not hard to create a test platform for your code.


The real fun comes when you simply can't test your code except by using it in anger. This happens quite a lot with trading systems, as the exchange simulators available are often either poor, non-existent, or don't even comply with what the suppliers of the exchange software say it does. This is part of life's rich tapestry I'm afraid. My approach is to make sure at least my side of the transaction is well-written and well-documented, so it can easily be changed quickly.

  • 3
    You "exchange" and "trading" software engineers are a unique breed. My friend had a series of mental breakdowns working for one such company. I never hear good things come out of that niche of the software industry.
    – maple_shaft
    Commented Jun 8, 2011 at 20:14
  • @maple Well, I don't do it any more myself. But unique? Nah - anyone can write crappy code, and most trading code is deeply, deeply crappy. However, like it or not it, is the basis for our society. Commented Jun 8, 2011 at 20:23
  • Yeah, I heard the same thing about telecom code and how many millions of lines were in switch control software. Then I joined a Telecom company and realized that if they had employed some programmers thousands of lines would have been sufficient. Commented Jun 9, 2011 at 5:06

Unit Testing; Mock applications/simulators.

This will take time, granted, and you may need to collect and massage sample data to create appropriate mock-ups, but it will pay off in the end: You will save yourself all the time and trouble you encounter when trying to test against external systems.

Used correctly, these tools will ensure that before you go anywhere near external systems, you're 99.9% sure that if your code fails, it's something in the external system/change of environment that caused it, not a bug in your own code.

I worked professionally for quite a while they way you did in school, and in many cases it was very effective. Eventually I worked under some people who forced me to abandon that methodology and use unit testing and mock-ups instead.

Now, I do not start any project without first thinking through the implementation of the testing phases - unit testing, mock-ups, simulators, sample data, etc.


I usually make a lot of syntax errors and logic errors

Maybe using a Linter can help you a bit here.

I was in similar situation with my previous employer. Our code base was really huge and to make any changes I had to code, compile then replace .class files in a dev-server then restart the dev-sever with restart script. And to my dismay, it will take about half hour to get dev-server up again.

Later I found out that Remote debugging the dev-server was also possible.

So here is what I did to optimise my process

  • First initial round of remote debugging, this allowed me see the exact code flow and exact values/states of variables.

  • Planing how and what changes I will make.

  • Making Changes and then comparing the diffs

  • Caching mistakes by using linter or by compiling.

  • Giving the hot fix by replacing the .class files and restarting.

Sometimes I would also include a hell lot of log statements to again check the code flow and to check check for values/states. This did helped me a lot.

Also using a IDE with good auto-complication can greatly help in reducing typos.

Hope this helps.

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