11–20 of 64 posts
I think this article would be better titled "Want to write some code? Get away from Visual Studio".
Perhaps better titled get away from the IDE. Every IDE has exactly the same capacity that he's ranting against. This is a rant against write, run, debug, repeat, not visual studio. Even Notepad++ has run in it.
Can't entirely agree. I'm not a grizzled programmer, so sometimes when I'm coding for microcontrollers the debugger winds up teaching me about some new quirk in architecture. It's often something I was aware of (endianness, some of the finer details of addressing) but had not yet actually dealt with in person.
I do most of my outlining away from the computer, with pen and paper. UML is your friend! http://en.wikipedia.org/wiki/Unified_Modeling_Language
I find when going to sleep is the best time to code like this. No distractions.
I adhere to this adage and find it to be true
One of the best lessons I learnt from my first boss was: “when your code doesn’t behave as expected, don’t use the debugger, think.” Can't entirely agree. I'm not a grizzled programmer, so sometimes when I'm coding for microcontrollers the debugger winds up teaching me about some new quirk in architecture. It's often something I was aware of (endianness, some of the finer details of addressing) but had not yet actual…
When it comes to a dynamic language, knowing how and what lead to a particular function being called is important and all that information isn't exactly saved on the stack trace---you have to step through to find it.
While you can get the benefit of clarity by stepping away from the keyboard for a while, I've found the best return is from test-driven development. TDD forces you to think about what you're trying to achieve before you try to solve the it. The thing I took exception to in the post was: > 5. Make small change to the code on the off-chance that it might solve the problem Whether practising TDD or trying to formalise t…
Guess and check, supported by a scaffolding of tests is not the path to being a better or more professional programmer and this is precisely what he's advocating against.
One of the best lessons I learnt from my first boss was: “when your code doesn’t behave as expected, don’t use the debugger, think.” Can't entirely agree. I'm not a grizzled programmer, so sometimes when I'm coding for microcontrollers the debugger winds up teaching me about some new quirk in architecture. It's often something I was aware of (endianness, some of the finer details of addressing) but had not yet actual…
However, a lot of the biggest headaches are conceptual and in which case taking a break from the computer almost always helps I find.