Programming and frustration. How to break through the wall?

Post Reply New Topic

Hi all,

I've been off all week, burning some vacation time I needed to use up by the end of the month (to all who haven't tried, I HIGHLY recommend the humble "staycation" as a de-stressing tool. I've done little other than sit at home in the living room, enjoying only the company of my dog and sweet silence - the lack of jarring "NEEDTHISNOW" co-worker demands or loud noises is amazing.) and have been letting my mind wander and address some of my stressors that I'd had little choice but to put off until later due to the fits-and-starts nature of my typical daily schedule.

One of the things that I've been thinking about is my history with IT skill acquisition. I'm pretty mean when it comes to managing networks, applying already-produced tools, configuring and/or securing systems, etc. but the one thing I never seemed to pick up on was coding. I've tried many times and am able to write programs in a few languages (most commonly Java, VB.net, and shell scripts) but they're crude and take me conscious effort every step of the way every time. I'm not at the level where I can look at a problem and have lines of code just start forming in my head as I think "That'll work, and then that, and then write a subroutine for this, and then..." It's gruntwork, start to finish. I know this might be one of those social things that a lot of us don't get, but there seems to be a prevailing mentality in the IT industry that the worth of a person is at least partially tied to their skill at writing code. Like it doesn't matter how good a network-wrangler you are, or how good your pentesting kung-fu is; if you can't code, you're lesser than those who can.

I've tried learning to code in the past, but a few things always seem to interrupt the process:
-Lack of real-world application for skills. Simply put, I can't seem to identify real-life problems that would be solvable by programs I could write at my current skill level. "Hello World" is getting kinda tired at this point.
-Frustration with understanding and/or applying new theories and concepts. I hate to admit it but I have something of an addiction to results. Once I've seen a certain number of show-stopping compile errors, shifted punctuation around, fought with this or that curly brace, and racked my brain to figure out what variable is out of scope, all with no real improvement or resolution, I feel a strong inclination to say "screw it" and do something else. Frustration has always been this way for me - I know I should "learn patience" but as some people here are probably better suited than most to understand, that's often easier said than done. Once I've failed a few times I start second-guessing if I'm even trying to learn things the right way and wondering if I'm just wasting my time. Needless to say, that feeds back into the frustration and is a real motivation-killer.
-Lack of exercises/practice suited to my current level of knowledge. I'm having trouble finding material for people who understand the basic premise of programming and have passed a good number of OOP courses in college (Illinois Tech, so nothing to sneeze at either) but just can't get into it outside of an academic environment. Most everything I've tried is either over my head from the get-go and assumes either familiarity with, or mastery of, concepts I haven't grokked yet, or is for newcomers and sees me wading through the same "Java was invented in 19xx by Sun Microsystems as a means of..." introductory material that I've read countless times.

So I guess what I'm asking is if anyone here who's an adept coder can guide me to some resources for getting back into programming, staying interested in programming, and most of all, getting over the frustration hump I seem to keep sliding back down. I'm getting aggravated with myself for letting frustration get the better of me but at the same time, I don't see the path through it. Should I try something other than text? Video tutorials maybe? I have a lot of technically-inclined friends but they're either engineers, netadmins like me, or hardware enthusiasts. Not many programmers among their ranks for me to bounce ideas off of.


Aside: I'd like to learn skills and/or languages that not only make me more valuable to my employer but also help engender a programmer's mindset so I can look at problems like a programmer and get to that headspace where they go, where problems become building blocks to take apart and move around until there's a solution. For what it's worth, I work in a mostly-Windows shop (one RHEL server, critical apps are MS SQL Server-driven) so anything that puts me on the right track for Win32/Win64 stuff is good.

Aside 2: I'm getting a referral to a mental-health professional to take care of some other concerns unrelated to this matter. Would this be something to discuss with them as well?

The only way to get better at programming is to keep writing programs.

Download MS Visual Studio express from microsoft website and start playing with that. You can build quick windows apps and have fun.

I am not sure it will come in handy for dealing with problems in life, but it may take your mind of any issues you have.

I agree with the way you've perceived the stigma against non-coder techies. I'm looking into SQA, Android or RHEL/Debian work while I continue sharpening my pentesting abilities (gotta get Kali Linux up!), and I've spent a month in an iOS shop being stepped on for not being a Mac user in the first place. Keeping track of projects I report bugs on or just have an interest in keeps me mindful of the OS level constraints you mentioned. Firefox Betas have probably taught me more about Windows than Microsoft itself, as have VMware, Eclipse, IntelliJ and scores of scripts, batches, utilities and exploits.

UPDATE: You may have seen it, but I spend a lot of time reviewing on http://www.codecademy.com/

I recommend Visual Studio 2010, MSDN, and a good free e-book or asking for help on Codecall.

You could try to find a problem that's small and not too far out of your reach, and then build up to it. You don't have to practice on a real world problem.


There is a pretty large amount of this that is unavoidable when you're learning a new language, and a certain amount that's unavoidable even if you're very familiar with it. One of the best ways to approach it is to make small changes, and run it after each one. The less familiar you are with the language, the smaller the change you can reasonably make.

There will be bugs, that's a given, but if you write a lot of code without trying any of it, you'll probably get several bugs at once, which is not only more frustrating but harder to deal with than one bug at a time. It almost never works perfectly the first time. That's normal.

If you find that something won't compile and you think it should, try a shorter, less complex version of it, and see what happens. If you think it should compile and it doesn't, then you know some assumption you made isn't right, so just trying to mentally sort through what it should be is probably not going to be useful, since if you could see what you were doing wrong, you'd be doing it right in the first place. Reproducing the bug in simpler terms reduces the number of places it could be hiding, and once you know exactly where the bug is, things frequently get much simpler. Frequently, finding the bug is the hardest part of debugging.

Compiler error messages are often very useful, but take them with a grain of salt. Sometimes a bug will cause some other part of the program to be broken and the compiler will complain about the broken bit rather than what caused it.

Since you aren't required to use any specific language for this, you should try one with a good REPL (Read-Evaluate-Print Loop -- basically like a command line for that language that lets you enter in expressions in the language and see the results). REPLs are great for debugging, figuring out what works and what doesn't, messing around with instant feedback, and so forth. (Some languages don't use the term REPL, but have one anyway.)


This sounds like something the mental health professional could help with. I think a lot of the frustration-related stuff is not really specific to programming (although it can be especially frustrating from time to time).


One way you could do it is to grab something that's a bit over your head, and look up the new ideas until it isn't over your head anymore.


The only way to find out if they work for you is to try them.

Thee only way to learn code is to practice it, text books can only go so far. This is especially true for debug coding. I am more of a visual software programmer myself, you could be amazed in what software can do to help with things.

Within Visual Basic 2008 which I use on occasion, I manages to apply real life problems to create the software. Lixe a finance tracker, keeping schedules, automating a database to catalog games, music, movies owned... I could go on, though I don't blan on creating them, its all very possible. The most significant thing I've created was a Multi-stopclock to time more than one thing at a time and almost made it so that a user could add an infinite number of stopclocks. It came with a fully funtioning options menu to chande the way it looked, the size and colour of it and such...

...I should get back into visual software programming...

Practice, practice, and more practice. There's no shortcuts - once you've practiced enough and "get it", when you hear about a problem the lines of code (or at least an approach to how you would code it) WILL come to you pretty easily.

As for how to practice - I understand your frustration with lack of real world problems. I can only suggest that you take whatever language you are most comfortable with, think of a problem you know how to solve with it, then think of a slightly more difficult version of the same problem that you might not know how to solve right now. Do what you can with it - Google for ideas on how to do the part you don't know - then do it, even if you find something on Google that solves it for you. Even just seeing how other people solve the problem will help you, though its always better to do it yourself - you're more likely to remember it that way, and it will help you build up your toolkit of problem types that you can solve. Do this with a bunch of problems, and try to repeat the exercise making it more complicated each time.

Here's an example. Say you have a text file that contains a comma delimited list of integers on a single line, i.e. "3,6,1,1023,45". Write a program to load the numbers from the file in to memory, sort the numbers into ascending order, and then write the numbers in order to a different file. For this you could Google for things like "how to read a file in Java", "sorting algorithms", "Java file parsing" etc.

Very useful advice for me, actually! I tend to bite off more than I can chew when I program. My functions tend to be too complicated. I did a lot of QBasic when I was a kid, and I almost never even used functions - most of my programs were one big, monolithic, "do-it-all" procedure! Once I started using more sophisticated languages that actually have real-world use, I could no longer get away with that...

That being said, my introduction to programming (at age 5) was a BASIC REPL on an Atari 800. It's probably why I learned BASIC as well as I did at such an early age (obviously hyperlexia was at play too - most kids my age couldn't even READ!) I've become pretty well-versed in C and C++ throughout my college education, but I do think a REPL would be a great way for me to learn a new language, and one I haven't used in way too long!

Are there no problems that you would like to solve with your own computer-based work? There must be data management, queries or repeated sequences of tasks on your own desktop that you could conceptualize as coding problems. If they work for you, then they would work for someone else.

I write some form of query, code or command almost every day, simply because it is quicker and more effective than any GUI solution to the problem. If I do something enough times, then I might package it as code, sometimes within a GUI, sometimes for others to share.

There are plenty of shell scripting languages, browser scripting languages and interpreters that allow you quick access to functionality, without all the hassle of creating a complete programme framework around your solution. Scripting within your spreadsheet or office suite, or as a repeatable shell batch command, is a good example of accessible everyday coding.

In my case, I needed to be excited about a specific programming project. Then I worked backwards and figured out which language to learn. In this case, Python, SciPy and NumPy.

I tried various books but found this quick course the best because it broke lessons down into tiny pieces without padding and fluff:

Learn Python the Hard Way

Zed Shaw also teaches other languages.