When I was first exposed to computers, I was fascinated with the concept that I could write “Hello World” and make words appear on the screen. As I’ve tried more advanced projects, I’ve found that I have a real problem with frustation, mostly in the area of debugging. It something doesn’t work as expected, or not at all, it can be exceptionally frustrtating for me to figure out. Sometimes its a simple but nonetheless obscure syntax error, sometimes a problem with my logic/algorithm, or sometimes an undocumented quirk with the language or environment. I find this maddening, enough to make me ragequit a programming session. How do developers out there cope with this?
In the past, I’ve created some bespoke business systems including an expense report system for accounting and a quoting system for a sales department. These were all fairly simple systems, yet I often found myself wanting to bash my skull into a brick wall. In fact it was so frustrating, that it completely drained my enthusiasm for coding. Nowadays I just write some simple bash scripts for my personal use, rarely touching any kind of development environment.
Any suggestions for reigniting my interest in coding without causing an aneurysm? It usually takes a ‘cool project’ to get me started, but what strikes me as cool can be rather random.
When I find myself frustrated with a given problem, its usually because I am observing that something is not working and not asking the obvious question of why its not working.
Sometimes I make a pretty exhaustive list of things that I tried that ended up not working. Don’t count these items as failures, they are only true failures if you learn nothing from them. Sometimes me and my team will spend a solid week of development time just to run into a dead end, but its important not to get discouraged. This was not time wasted, this was time spent thoroughly demonstrating why this particular method wont work.
Your discussion of failure made me realize what part of the problem is. If I can’t code it right the first time, I consider having to debug a personal failure. I hate screwing up, and it seems impossible (for me anyway) to write perfect code the fist time. I suppose I need to reframe this outlook, but I really strive to avoid mistakes.
And then there’s the wasted time. As you said, you can find yourself down a dead end path all too easily. This causes slipped deadlines, though sometimes they’re self-imposed.
Thanks for the constructive input. I’ll have to chew on this some…
When you find the answer - please, tell me.
I code games as a hobby. More of a start working on a system and whenever I hit a massive wall I get angry and quit…
First, I find testing helps a lot on this front. TDD in particular.
Second, Committing every time the tests are all green, and I’m happy.
If you’re adding tests as you go, then the problem can really only appear within the lines that have changed since you last committed. Or with things used in that new code. Much smaller scope than… ‘in there some place’
With all that in play, I rage revert early and often.
If I can’t find the cause of the problem, revert back to my previous green state, and type out the change again. Often, I’m not able to re-produce the issue at all the second time around. Which means it was probably a dumb typo.
And if you’re looking for something cool, have a browse over here: http://codekata.com/
I think ‘Kata08: Conflicting Objectives’ is cool, in the sense that result is interesting.
This way 1) If you have to come back to the project, you are in a working (if incomplete) state. 2) You are not publishing an incomplete thought for your coworkers to get puzzled at, and 3) you don’t want to step on coworkers toes by merging bad code into their good code.
@Chris_Brake@judahnator This may come as surprise, but all the projects I’ve worked on have been solo efforts, without the benefit of a code repository or versioning system (well other than the occasional manual backup.) That’s mostly because I didn’t know such things existed at the time I wrote the software, and without a team the benefits are less obvious.
I don’t have much formal training outisde of some freshman level procedural programming, and instead learned by getting my hands dirty. (I find most IT educational material, whether live, video, CBT or written to be impenetrably dull and have much better retention if I learn by doing.) That doesn’t mean that my methods don’t need to be adjusted or changed.
That sounds a bit extreme. I mean, it depends on why you’re debugging. Did you do something boneheaded, or did you end up somewhere unexpected because the code you’re working on is full of 15 years of stupid shit? It sounds like what you’re really asking is how to manage complexity, and often there’s just no way to do that without getting your hands dirty first.
Maybe there’s people who are good enough to read a large amount of code and just know everything about it, but if there are, then I’m not one of them, and they seem to be extremely rare. Finding a way to account for uncertainty might go a long way towards making the whole process more doable.
Well that’s likely a contributing factor.
I’m ignoring your lack of formal training on purpose.
I would highly recommend git, even for solo projects.
Just run a git init in whatever kind of project directory you usually make. And work on building up a habit of committing.
I think of commits like checkpoints in a video game. Ok, I’ve made it this far let me save my progress so I don’t have to start over at the beginning of the level.
It will let you use things like git diff to get a view of what changed since the last commit, revert back to green and so on.
This is all local, and stored in a .git folder in the directory.
Only if you want a free off-site backup, consider pushing to github (or similar) every now and then.
The only thing I’ve used git for is to occasionally check out some open source code I wanted to build. From it’s open source origins, it should be great at tracking text-based source code for C++ and the like. Can it track proprietary platforms, like say an MS Access database, and the associated Visual Basic forms and code? I imagine Xcode would be easier to track since I think it’s all text based at heart. Please pardon my ignorance here.
EDIT: Looks like in the case of MS Access you’d need Team Foundation Server, ‘free’ with Visual Studio.
Suggestion: Don’t try to force your brain into alien ways of thinking — there lies the path to madness. Find a language that works the same way you think, and master that.
I started programming with BASIC, then COBOL, then Pascal, then a veritable laundry list of programming languages over the last 40 years or so. You know what programming language I can just write and write and write and virtually never make a mistake in? Perl. Specifically, Perl 5. Not JavaScript, Erlang, C, Lisp, Lua, Fortran, AppleScript, Java, Python, Assembly, Prolog or any of the others. Perl. That language fits the way my brain works as snug as a glove.
You can learn to program competently in any language, given enough time, practice and patience, but the best way to avoid frustrating debugging sessions is to not make mistakes in the first place. IMHO the best way to do that is to find the language that best matches the way you think. You’ll know it when you find it — everything will seem oh, so natural and easy.
How to get re-interested in coding without smashing your head into a wall?
buy a raspberry pi
buy a hardware widget kit like the sunfounder da vinci kit
play with the hardware/software and use python to make real world things do stuff via the Pi IO port
I learned to code in Pascal and C in the 90s and have spent most of the time since 2005 not really touching code and in that time doing anything “fun” on PC like graphics has turned into a shit-show of boilerplate and learning frameworks/libraries. (back in my day, mov ax,13h … int 10h … then stuff bytes at address $0A00:xxxx)
So… if you want to exercise your brain doing fun stuff, don’t do that. Get a pi and some hardware to drive with it. You might even end up making something useful
Very few people write code perfectly the first time, even professional programmers. Not the second or third time either. Witness the zero days still being found in Windows, Linux, macOS, etc. Some of them in components written and re-written continually from decades ago.
Coding is hard. Failing is an opportunity to learn. Cliche sure, but this shit is hard. Just ask @wendell about date processing Most of the time if you think something is trivial you’ve underestimated the complexity of it
Don’t feel bad for writing bugs, literally no one on the planet writes code correct first time, outside of extremely trivial toys.
I was like that… I mean you’ve seen my “Hello o/” thread here. And to be quite frank I still am like that.
Yesterday or something (don’t recall bit of a haze atm) I was working on my ai companions and integrating the new vision sensor into their base behavior and for some reason enemies recognized the player but not the squadmates… the suadmates recognized the enemies tho… even tho they were all using the same code.
Turns out it was the architecure of how I “assembled” them… but did I find that out right away? No. Did I find that out after 10 minutes of diligent poking and prodding? Oh no. Did I walk away from the computer and watch something interesting to forget the current conceptions I had about it and get a fresh perspective when I came back later? You betcha I did.
Being a young person you may not know this but when you write something (irl) and then read it, you’re very likely to overlook any typos you made for the simple reason that you know what it should be. It’s a way to conserve energy by not having to reevaluate things constantly.
If you know that you can work around that. When you’ve bashed your head against the wall for a while and the crunchy sound ain’t coming from the concrete it’s time for another perspective by getting a bit of distance.
Perspective brings me to the next aspect. If you can’t figure out a problem you might be asking the wrong question/asking the question in the wrong way. When you can’t find the answer to the question, change the question.
Next aspect; compound problems. Don’t build a monolith and expect it not to drive you insane. Build iteratively. Figure out your supporting pillars, the core things you need to make your tech work then do a separate, standalone proof of concept project for each of them. Once you get the central pieces working on their own you build the bones and connecting tissues and soon you’ve got yourself a little necromorph shambling around.
Last aspect; resistance to frustration. Just like the borg it’s impossible to resist the frustration inherent in software development. But you can work in a way that keeps you motivated.
You have to create a positive feedback loop. Small successes that keep you going through the drought-y parts of a project. The first step to that was the previous approach of building in pieces then assembling them. Each piece you get working will make you feel like the king of the world before the computer will slap you with the harsh reality of your fleshy limitations again. But those periodic highs will keep you going longer and with more fervor than if you built, built built and then kept hitting a wall.
Another part of this aspect is project planning and making your wins visible. When you chop up your projects into milestones and sprints, each time you reach one… reward yourself. Piece of chocolate, watching tv, whtever. You’re the master of your skinnerbox, figure out what makes you push the button and use it.
When you’re done with one… don’t delete or archive them. Move them into a “Done” category that’s well visible. Sometimes our memory ain’t the best when we’re at a low point, so looking up at a mountain of tasks ahead can be daunting. If on the other hand you can just look back and gain confidence from the mountain of things you achieved, suddenly the way ahead doesn’t seem to insurmountable.
