A programmer’s greatest enemy is getting stuck. A crucial skill in programming—and one that many of my beginning game programming students lack—is the ability to recognize when they’re stuck, to get out of being stuck, and to avoid getting stuck in the first place.
Indeed, it’s a skill I’m still learning myself, although the contexts in which I still get stuck are shrinking with time, study, and experience.
This morning, as I downloaded crash reports from Apple, I realized I was dreading my job today. I started looking for other things to do—checking email, reading news—anything to avoid what looked to be a tedious round of programming.
I asked myself what it was I was dreading exactly, and it took me a moment to figure it out. Getting stuck, came the answer.
It wasn’t the debugging that bothered me. Crash bugs don’t scare me. Usually I find that crashes are easier to fix than more insidious problems like memory leaks or uninitialized variables. With a crash, at least you know where to start looking: right where the crash report says to look.
Ah, but those pesky crash reports. That was the source of the dread. You see, I’ve used crash dumps for debugging before, but never from Apple, and never in Xcode. What would be involved in using these reports? Could I just drop them into Xcode and have them point me to the source code, or would I have to painstakingly read through the report myself and interpret it manually? How helpful would these reports be in directing me to the actual source of the crash?
Part of the problem was that the reports lacked debug symbols. I could see what module caused the crash, but apart from that there was only a byte address—no source file name, no line number. So to use the report properly I would need to find the .dSYM file associated with the version of the app that was causing the crashes, and hook it up (somehow) to the crash report. How would I “hook it up”? And did I even still have the .dSYM file around?
All of these thoughts were mere intuitions, haunting the back of my mind as I browsed the reports. It was only when I stopped and thought about them that I realized: I was dreading programming this morning because I was afraid of getting stuck.
What if the process of symbolicating the crash reports was complex and finnicky? I could spend hours reading man pages and trolling through forums, look for tips on how to symbolicate a report. Sounds ridiculous—but then sometimes these little bureaucratic processes are ridiculous. Ask anyone who tried to get codesigning working for iOS in ye olden days. I hate reading man pages and semi-relevant forums looking for answers to questions about how to overcome silly barriers. I was dreading that.
Or worse—what if I didn’t have the .dSYM files around any more? How could I use the crash reports without symbols? Maybe they’re buried in the app package? If not, maybe I had a backup of the files on Time Machine somewhere. What if I didn’t have a backup—what if I had to try to interpret the reports by hand, without symbols, using mere memory addresses? Ack! Tedium awaits.
Now I know all this sounds pitiful. It is. But I’m exposing my morning whinery to illustrate a certain kind of thinking that all programmers wallow in at times.
In my years of experience as a lead programmer and a teacher of programming, I’ve learned that when a programmer is really struggling—when his or her productivity has really sunk to the bottom, and days go by without much getting done—dread is usually involved. That programmer is stuck. And when a programmer gets stuck frequently, or stays stuck for long, unemployment can’t be far behind.
In my first “real” game programming job, at Origin Systems circa 1995, I befriended a programmer who had been there for years. He was a terribly nice chap, and he was kind to me as a newbie in the games industry. I liked him, but after I had worked there a few weeks, he confessed that he was struggling with his coding. He had been weaned on C, and all this C++ tomfoolery mystified him. The company was moving toward Object Oriented Programming—had already moved that way, in fact—and he was being left behind. Although I was a n00b, I had studied C++ while at college and understood it pretty well. So I explained OOP concepts to him, showed him why C++ really was a better C, and tried to help him modernize.
I didn’t realize it at the time, but it was too little too late. He understood the concepts I taught him. But something had happened to his confidence. He kept showing up to team meetings with new excuses for why he hadn’t made any progress that week. “I had this terrible bug that took a couple of days to track down. It was a killer—Tony helped me with it, you remember that don’t you Tony?” (Tony, looking unconvinced:) “Oh yeah, that was a killer.” “And then I had to go and help the other team get their installer working and then I got sucked into a design meeting they needed me for…” He had all sorts of stories about useful things he had done that week, none of which were getting his assigned programming tasks done.
Since then I’ve seen this a thousand times. Shoot, I’ve done it more times than I’d care to admit. Showing up to progress meetings with beautiful excuses.
Only a couple of months later—just a few months into my own career—that programmer got fired. I was shocked, I was horrified—nothing in business is as scary as the first time you see somebody get the axe. It’s like watching a death. Rational or not, you can’t help but feel you just dodged the bullet yourself. Axes, bullets—unemployment isn’t a pretty thing.
“He wasn’t making progress,” they told me when I asked why they let him go. “He just wasn’t getting things done.” He got stuck—real stuck—and he couldn’t get unstuck in time.
Most stucks aren’t as bad as that. Most are half-day or one day affairs—maybe a few days of avoiding the boss’s searching eye, playing a few too many rounds of Robot Unicorn Attack when you should be coding. But it still stinks to be slinking around at work, not doing the job you (usually) love, just because you can’t figure out how to move forward. Big or small, stucks hurt the soul.
A programmer’s greatest enemy isn’t the tools or the boss or the artists or the design or the legacy code or the third party code or the API or the OS. A programmer’s greatest enemy is getting stuck.
Therefore a crucial step to becoming a better programmer is learning how to avoid getting stuck, to recognize when you’re stuck, and to get unstuck. More on this next time.
64 Comments
Holy cow. You just described the biggest bump in I had/have in my life.
Maybe programming is a bad choice of career for overly-anxious people.
Maybe thats the reason I don’t have a career anymore. I’m just stuck.
The thought of “something boring coming ahead” is worst than actually solving the issue.
I’m so waiting for the next post on the subject, you have no idea.
great post and incredibly true!
Word “stuck” was used 14 times. In any other ways I agree with You.
I think it would have been kind if you mentioned something about how to avoid getting stuck.
Great read. Perhaps this could more easily and generally be summarized as a specific instance of the ‘fear of the unknown.’ Programs that we write ourselves, for the most part, are all about using well-thought out and well-used tools. Our work complements the nature of our want to partake in processes that are cohesive and easy to picture from a big perspective.
I think a good defense in this could be found in a love for technology and strength of presence. If we can convince ourselves that some new software tool or piece of code that you have to review is just another way to learn and develop learning for technology, things seem a bit brighter. It’s attached to the mantra that “there’s always something more to learn.” Your dread of finishing a task slowly becomes then an excitement (or at least a looking-forward-to) in learning and applying a new concept. For me it even becomes “how quickly and efficiently can I finish this?”
Hey Jeff,
Remember me from the IBM days? Congratulations on making the front page of Hacker News. I was hoping you were going to say that a programmer’s greatest enemy was Oracle, but I guess that’s just mine. Actually, the thing I fear most is indeterminacy. When things fail occasionally and randomly. Good to see that you’re doing well.
Cheers,
Mike
Holy smokes I just now saw who this was. Howdy, Mike!—so sorry I didn’t reply sooner! Email me or something!
Whoa – if you really deliver, in usefulness your next post will outweigh all the other blog posts I’ve read in a year.
Great article. Definitely rings true.
Thanks.
I certainly have this problem. What most often gets me “stuck” is environment issues. If there’s a problem with the CODE, I can almost always come up with another clever work-around to isolate or fix it, but I’m particularly poor at figuring out why it is that the build works on every OTHER machine but not on mine (or whatever the environment issue of the day happens to be).
I am certain that if you paired me up with someone good at troubleshooting environments, my productivity would go up by a factor of 1.5.
Nice post! Huge cliff-hanger though. I do that sometimes when I get stuck in the middle of writing a blog post
.
Nice read.
I find this related to the Four stages of competence
Sometimes, there’s something you don’t know you should be doing until you’ve learned it.
Yes! That’s absolutely part of thinking behind this post. We talk about the four stages at the Guildhall a lot—it’s part of how we thinking about learning and teaching programming. You’ll see it again in my next post.
I’ve been writing software for 20+ years. You’re absolutely right. Getting stuck is such a killer because, often, when you really get stuck, you can’t figure out how to get unstuck. I’ve developed tricks over the years to get my mind to loosen up so I can start figuring out the problem– like going to a movie, that usually helps. Sometimes playing a game will help, but sometimes playing a game becomes an escape. Most amount of time you can blow on a movie is 90 minutes.
Anyway, when there’s too much uncertainty– for instance, you’re architecting something new, that’s never been seen before, or you’re integrating three different technologies, all of which you’re just barely coming up to speed on to begin with, getting stuck can be terribly painful and kill huge amounts of time.
sometimes there are more things you need to think about than can fit in your head, and by the time you get to the end of thinking about something, and need to refer to something you thought about earlier, you’ve forgotten it, because you just crashed the stack in your head. And so you try again… and again… and again… because you can’t figure out how to do it without thinking about all the things you need to think about. And so you’re stuck.
I hate it.
Also, I’m stuck right now, or I wouldn’t have hit HN and seen this post.
That’s an interesting way of looking at it. But I think stuck is more an effect than a cause. The cause is things like avoiding learning new technology (your C programmer that put off learning C++) and not being able to figure a way around difficult problems.
We all face change. We all hit problems where the lack of documentation, tools, or bugs in 3rd party programs stop progress. But the ones who let that stop them – that’s stuck. The others figure a way through and continue.
That was excellent. The stuff you’re describing is exactly what I experience all the time. It’s good to know I’m not the only one.
I agree completely. But I’d add another cause of getting stuck. Namely, the ‘too many things in my head’ syndrome. That’s what happens when you’re doing both development, debugging, helpdesk and even some project management simultaneosly. And when you turn on your computer, you know that there is no way to accomplish what you’ve planned for today, as in less of 30 minutes you’ll be interrupted by a phone call with some urgent matter. In that circunstances, you tend to think it’s simply not worth to start programming.
Man, no kidding. That’s a big one for me too. I call this the “spin up/spin down effect,” and my wife and I bemoan its impact on getting things done all the time.
It’s 6am on sunday here in Buenos Aires (Argentina), I’m awake because I can’t sleep. I have insomnia, so I got up to drink a cup of tea and do something until morpheus hits again. While I was trying to get sleep I couldn’t help but to think all the wasted hours I spent these last couple of days because … I GOT STUCK. It usually happens to me on the last days of the project, when the clock is ticking and the deadline is coming; when you have most of it done and all it’s left are the DETAILS, small fixes and some TO-DO’s. I HATE when it happens. Nothing is better than when you’re inspired, just vomiting lines of code almost without thinking them and it feels like you’re writing a Concerto or something.
Anyway, EXCELLENT article, I’m glad I read it just now. I’m going to try to get the inspiration back and get UNSTUCK.
Thanks, Javier. Getting stuck both sleeping and programming in the same week really stinks. At least it is the end of the project….
You just got yourself a subscriber.
Can’t wait to see the solution.
Check my next post for more thoughts on getting unstuck.
My biggest enemy are non-IT CEOs who send me 200MB .pdf files containing 8 raw bitmaps.
But I have to disagree with you about being stuck. A good programmer is stuck very frequently, unless he is responsible for databases or GUI. But there is a good line I know from Rareware, “A problem that cannot be solved for hours in the evening is easily solved in 10 minutes the next morning.”
That’s a great quote from Rareware.
If I’m reading you’re point about good programmers getting stuck frequently rightly, I don’t think you’re disagreeing with me. I think you’re agreeing. I’m not saying good programmers don’t get stuck. I’m saying that good programmers are conscious of stuckness as an enemy and pay attention to avoiding getting stuck and getting out of being stuck. And surely database and GUI programmers get stuck just like any other area of specialization.
I think I would agree with you on “stuck” being the source of fear in the early year(s). However, I think my greatest fear and enemy now is getting bored. If you replaced the word “stuck” with the word “bored” throughout this entire article, I would identify with it more.
“the ability to recognize when they’re , to get out of being , and to avoid getting in the first place.”
cool post! thanks!
What ever happened with your iOS debug task?
Was debugging the dumps as difficult as you thought it might be or was it pretty easy?
It turned out to be super easy. Just drag the crash report onto Xcode’s “Device Logs” entry in the Organizer. Symbolication happens automatically. Magic.
Isn’t the word automagically?
Ah yes. I suppose I could have simplified. Just as
i += 2;is an improvement on
i = i + 2;Great post!
Everybody in every profession that ever existed gets stuck sometimes, the best and the worst of them. What’s key in getting past that is what you do after you’re stuck. In I.S. it’s best to start bringing in additional resources (searches on sites, books, help from colleagues and/or coworkers) and see if they can give you a fresh prospective on the situation. And it’s important to keep those higher-ups in the loop as well. The worst thing you can do is to let it go on and on and as deadlines approach, they think you are just rolling along without problems. Our egos can be our worst enemies.
Communication is extremely important and worst case, can save your job!
Edison tried many different things before he got the light bulb to work. He told a reporter who asked him if he felt like a failure for having tried 9000 things that didn’t work “No, now I know 9000 ways to not make a light bulb.” There’s a museum in New Jersey that has a large number of these failed tests on display.
Errmm, wouldn’t that be ‘Best case’? Just how bad *is* your job, anyway?
yep totally agree..i learnt to “raise the flag” as soon as i get “stuck”
I really enjoyed your article. I’ve pretty new to the industry and I get super frustrated with stuck moments quite a bit. I’m looking forward to your follow up post.
The greatest enemy of a programmer is his wife!
This can be true….and don’t forget, his 2 dogs who think that when work is over it’s all about them.
If you are getting stuck, then you are not doing it right (probably from lack of experience). I would estimate that 99,99999% of all code written is not doing anything new/exciting/groundbreaking. Most of the code written today is trying to duplicate what somebody else has already done. So, if you are stuck (instead of going to see a movie), why not trot over to your local university library or search the interwebs for how someone else did it. Also here is a few tips:
- Ask yourself, “what am I trying to do?” A short user story is the best way to think of this. Three sentences or less.
- Ask yourself, “what is the simplest thing that could possibly work in this situation?” Don’t optimize and don’t be clever. Clever people aren’t good programmers and they are terrible team members. Be obvious and deliberate (principle of least surprise). Don’t write code just because you can (oh, remember that really cool non-locking list implementation, I should write one of those…).
- Ask yourself, “why can’t I do what I am trying to do?” If you have control over the code, then maybe you don’t understand the API (probably) or a proper API hasn’t been provided (also probably)
- Write unit tests (separate from your production code, DO NOT PUT THE TESTS IN YOUR PRODUCTION CODE). Writing separate tests will help you distill the problem into what you can and can’t do. Also, you are making small incremental progress along the way that can be demonstrated to others.
- Practice…
I’m surprised, frankly, that a programmer would claim never to get stuck, or that getting stuck is a sign of “not doing it right.” I suspect that the only programmers who never get stuck are either those who haven’t programmed much, or who work in a pretty constant environment, doing similar things with similar tools each day.
I got stuck yesterday—twice!
The first occurrence took about an hour and a half to resolve (which is a long painful time when you’re in the middle of it). I was trying to move my iOS project from using the GCC compiler to Apple’s recommended LLVM 3.0 compiler. But whenever I used the LLVM compiler, in Release configuration only, the app would crash in a really peculiar place: in the middle of a template function that was used as a comparison predicate being passed to std::sort(). Here was the function that was causing the crash:
template< typename T >bool compare( T a, T b )
{
return a < b; // Hard crash with LLVM in Release mode only! EXC_BAD_INSTRUCTION.
}
This almost immediately put me into a stuck state. How do you debug code that crashes on a less-than operation? I did searches on “LLVM EXC_BAD_INSTRUCTION” and the like, and of course all the results were totally irrelevant to what I was seeing.
The program ran fine with GCC. But was that because GCC was overlooking some real flaw that LLVM had exposed? When you’re stuck, you don’t know who the good guys and bad guys are. It’s hard to know whether to go up or down or sideways—every option looks reasonable.
I found the bug—I came unstuck—by narrowing the problem. First, I got rid of the calls to std::sort() that generated the error. The program ran fine, so this confirmed that the problem really was something to do with this code—it wasn’t, for example, just a memory corruption that had happened earlier and only manifested at this point.
Once I was sure that std::sort() plus this comparison function were involved with the bug, I tried doing the same thing right at the start of the program—right at the start of main(). Sure enough, the crash occurred there too. More confirmation that context was not the issue.
Finally I isolated the problem code into its own project—a project for which the main() function did absolutely nothing but call this code, and for which there was no other code at all! The problem still occurred. But again, in Release builds only.
So then I started comparing Release build settings to Debug build settings, considering what difference might account for the change in compiler behavior. Fortunately, my first guess was correct. LLVM has a “Generate Position-Dependent Code” option that was enabled in Release but not in Debug. When I disabled it in Release, the problem went away.
I was then able to further confirm that the problem occurred whenever you tried to use an inline function as a function pointer argument to another function, when Generate Position-Dependent Code was enabled.
That was stuck. It was pretty bad stuck—at least, it felt like it was. But it wasn’t because I wasn’t “doing it right (probably from lack of experience).” It was because I was doing what programmers often do: move to new compilers, new platforms, new tools, new languages, and these new situations often throw up mystifying challenges, up to and including arbitrary bugs.
Stuckness is not a function of experience or even of programming mastery (which are not, BTW, the same thing). Stuckness may be a function of trying new things. And if you’re programming without trying new things… well, I wouldn’t place bets that you’ll be programming for long.
(BTW, to retort your argument, the “stuck”-ness in your reply was caused exactly because you weren’t doing it right because of lack of experience with the LLVM compiler. You probably will remember how to solve that problem quickly the next time
)
Full disclosure, I have also gotten “stuck” plenty of times when trying new things, and am definitely not a “master programmer”. However, like any other craft, it is good to have a toolbox full of tools to use in various situations. Also, your followup post on tips for getting unstuck was good reading.
Very interesting topic. I think what Joe is missing the deeper point of this topic, but what is even more interesting, which you cover, or some of the other commenters propose, is the root cause. I’d say, if you’ve never been stuck, you are a very green programmer, or aren’t challenging yourself too much. Any time someone gets their nose to the grindstone, pushed by a deadline, tired, then they miss the easy things like #pragma, or “duoh! I’m pointing to the wrong database”, when, had they asked someone else, or taken a short walk, they would have solved the problem in 2 seconds. Now, there’s another topic you are touching upon, let’s call it getting stuck in a rut. This is where the C guy was. Procrastinating. He really didn’t want to do his job (learn C++), so he found all manner of ways to procrastinate and do other stuff. (Funnily enough, C is still heavily used, like an OS for ex, so getting fired was probably a good thing, he can go work at the many places doing just fine with good old K & R ANSI C.) So this is the deeper question, I’ll read your next set of posts, thanks again!
Good point about getting “stuck in a rut.” In these posts I’ve been focusing on “immediate stuckness”—getting stuck in the middle of a single task. But when you’re continually stuck, or when your whole career—or even sense of purpose in life!—is stuck, it’s a much deeper kind of stuck. Much more horrible too.
stuck ? Stuck ? Really ? .. rarely do I every get stuck ..of course I have many years of experience in a number of environments. My biggest problem is Not getting paid anywhere what I am worth. I am typically hired for jobs that others are unable to do, but i get paid the same. I have to face things like doing internals programming for a software system with insufficient internals documentation, writing com servers using 11 year old com technology to interface to an unsupported software system (i.e. No one at the parent company seems to know anything about their COM software, I have to do testing just to find how to interface to their stuf (even conceptual stuf)). No, I don’t get stuck I just am forced to face difficult situations and given little time for completion. … come to think of it i guess my pay rate it … STUCK (;
Hey Superman… some empathy could be a good thing here
Oh… and a spellchecker.
thats so true..getting stuck is a killer one indeed
IMHO, falling in love with the tool is a big reason for this. When we invest our time and achieve a certain level of competence in a certain tool, at some point we develop a liking for it. Because we are getting our perks (money, respect etc) from the tool, we feel like giving back to it. That’s the point where we shift our identity from a good programmer in C to good C programmer. If I have to learn C++ to do the same thing, my mind would constantly resist “its the same thing.. I can do it using C itself.. why this new shiny tool.. I will wait this fad out” Once you wait enough on the “fad” and reality starts staring, it then starts becoming an overwhelming proposition because the new tool has progressed already and you only have to play catchup.
One way out of the mess is to realize that we are not exactly starting from scratch though it might look like it. So the respected C guy is not going to be a total newbie running for help. This convinction can come if we start dirtying our hands. Further, we should realize that the effort being put in will make us more rounded. Finally we should see the tool for what it is… and separate our love for it from its utility.
Wow, goodsammy. Incredibly well said. I can’t add anything to that—I just hope other people here read your comment.
Beware the Ides of Functional! Algol-ish ain’t (necessarily) the future…
Also, in environments where the rate of change “seems” low (product development instead of consulting), you could lure yourself into a comfortable corner thinking that your investment will last forever. You can see the cracks in your shell but you dont feel like you are not needed till that big migration happens when your project is moved to use the platform you have been avoiding or your humble self is eased out into another project with a different environment.
Perfectly described. Great post.
“He had all sorts of stories about useful things he had done that week, none of which were getting his assigned programming tasks done.” … “He wasn’t making progress,” they told me when I asked why he got fired. “He just wasn’t getting things done.”
I’ve seen this sort of thing before, and I wonder. We all admit that such a person is smart and able-bodied and even doing useful things. These things just don’t happen to be the assigned portfolio. Why do companies have so much trouble making use of such people? Surely a sufficiently-enlightened organization could find some use for this person that would easily justify their employment.
For example, everybody’s company has a giant codebase that needs refactoring, old bugs fixed, and so on, right? Or you have people working inefficiently because they lack some internal tool support that nobody individually feels they have time to write. Or we really wish we had some more unit tests, but never seem to write them. (Or maybe we just need somebody to bounce ideas off of.) We preach to programmers till we’re blue in the face that these things are everybody’s responsibility, but they never seem to get done. Now here’s somebody who might be perfectly happy to do nothing but this ‘extra’ stuff that nobody seems to have time for (but wastes time by not having). Why not let him, and take that much pressure off everybody else?
Some industries essentially force all employees to be fully vertically integrated, and other industries allow much more specialization, and still others are happy have a Minister Without Portfolio, and it’s not at all obvious to me that software should always be the first. I think it’s actually more a shame for the company than for the former employee: you’ve gone to the trouble to hire somebody, to let him learn the codebase, and he is doing useful things, and the response is to fire him. What the!
All of the above… and pointing out such facts seems to be traditionally a Career-Limiting Move, unfortunately
Although getting stuck can be a hassle, it can help make you think differently that you usually do in trying to find a way to get unstuck. But nevertheless, it’s stressful just the same.
I have found in the past that getting stuck can start from the beginning of project/task, when you as the developer take on a little bit to much.
When I first started as a developer this was a regular occurrence for me, and when you get stuck on a “small bug” the above snowballs.
Like you said if you can identify how not to get stuck, life becomes a lot easier.
Great post.
You’ve put your finger on a huge part of the emotional impact of being stuck. When you’re stuck, not only is it frustrating to be stuck, but you’re also conscious of the backlog of tasks waiting for you in the future. You know that the longer you stay stuck, the later you become with your work overall and the more ominous those future tasks become. I know that for me, personally, if I just have one task to focus on, even if I’m stuck it doesn’t feel to bad. But if I’m stuck and I’ve got to take out the trash and I’ve got to take Jimmy to the dentist and I’ve got to finish my tax return and I’ve got to get ready for the birthday party… the pile of tasks quickly turns to anxiety and dread.
So maybe along with the advice, “Don’t get stuck” we should add a corollary: “Plan to get stuck, and give yourself ample time, so that the backlog doesn’t turn nasty.”
That is true, and even I have just got stuck on a project I am working on, and instead of find a way around it, I just left it and started doing other things, I just realized I need to go back and get it done
IE is the (web) programmers’ greatest enemy.
Stuck because IE sucks? (it even rhymes!)
This “stuck” you are talking about is not really “stuck”, it is simply called “Procrastination”.
Stuck would be if you are looking at a bug and actually trying to resolve the top priority problem that you have and are not able to figure out what is going wrong as well, you are then stuck.
Procrastination is when you are doing everything but the most important thing that you are supposed to do (like me now commenting on this weblog thingy
As for “uninitialized variables”, ever heard of this awesome tool called valgrind?
Also quite a few compilers will nowadays nicely warn about these kind of situations when given the proper warning flags.
Enjoy 2012 with the newfound wisdom that procrastination is your worst enemy…
Thank you for gracing us with your profound wisdom, Jeroen.
“I asked myself what it was I was dreading exactly, and it took me a moment to figure it out. Getting stuck, came the answer.”
I just wanted to let you know that I thought this was brilliant. I’ve actually been doing this today. The reason I found this website was because I was reading semi-relevent and interesting articles on the internet instead of working through my discrete mathematics text, which frequently leaves me “trolling through forums” trying to figure out how to develop some method for a proof. I look forward to reading more of your articles in the near future.
So funny to have read this after spending a night being stuck with an assignment for my Java class. After reading your post, I had to re-evaluate what I was doing, which was basically trying to force my crappy and unorganized code to do what I wanted it to do. I was stuck because I couldn’t get it to work but also because I couldn’t break free from the fact that the code wasn’t working, and possibly not going to work at all. I was “patching” instead of “coding” – bad, bad, bad.
I’m not an expert in Java and programming, and I still have a long way to go to be able to say that I’m at an intermediate level of expertise, but at the level that I am now, I should be able to recognize when my work lacks quality.
I love learning!
“C++ really was a better C” – I don’t think like that.
OOP is not necessary, too.
UNIX Philosophy is the best.
11 Trackbacks
[...] A Programmer’s Greatest Enemy. Share this:TwitterFacebookLike this:LikeBe the first to like this post. This entry was posted in [...]
[...] in his latest blog post talks about greatest enemy of a programmer. Also, excellent advice for programmers on [...]
[...] Wofford singles out “getting stuck” as A Programmer’s Greatest Enemy. Stuck as getting stuck with a problem that you just can’t solve. This situation gets [...]
[...] A Programmer’s Greatest Enemy [...]
[...] Jeff Wofford: A Programmer’s Greatest Enemy [...]
[...] O estar atascado por no saber qué hacer después (cuál es el siguiente paso). Estar atascado puede ser uno de los peores enemigos del programador así que hay que tener un arsenal de herramientas para [...]
[...] came across an interesting set of posts by Jeff Wofford where he talks about programmers getting stuck and it made me think that, despite its faults, agile software development does have some [...]
[...] came across an interesting set of posts by Jeff Wofford where he talks about programmers getting stuck and it made me think that, despite its faults, agile software development does have some [...]
[...] “A programmer’s greatest enemy is getting stuck.” [...]
[...] A programmer’s greatest enemy, Four kinds of stuck, Keep taking steps forward (pfleidi) [...]
[...] blog entry by Jeff Wofford inspired one of us to talk about the notion of “being stuck” in software development. [...]