The punches are pulled in this piece. Not only is the compiler continuously complaining, once you ship code, your customers call in to complain about every conceivable bug and a great deal that weren't conceivable. You can have thousands of happy customers, but you as the developer will hear from the three guys with obscure configurations and bizarre setups encountering bugs. Shipping software is ten seconds of "Hooray", followed immediate by a breakdown of what terrible things are already wrong with the next release.
I'm surprised any of us can hold up under the withering torrent of negativity that is any serious programming job.
I actually don't mean this as a complaint, either. I've adjusted. I've been doing this for 15 years. But I've been sort of stepping back lately and looking at my job from other points of view, especially as I deal with coworkers who aren't so adjusted/adapted, and not only do I now understand where they are coming from, I find myself wondering how adaptation is even possible. It's absurd how negative the interactions are. Keep track someday of your professional interactions and look at how many of them are negative; bug reports, missed deadlines, "we can't do that", etc. Or perhaps, don't, if you've never thought about this before. I sure hope you have an otherwise positive workplace.
But this is true of any "producing" profession. Any time you're creating something and "putting it out there", there's going to be a huge stream of criticism from every direction. Artists, writers, musicians, engineers, carpenters, etc.--all of their work is constantly under scrutiny by "the customer" and/or "the boss".
Even non-producing professions have to deal with constant scrutiny of their performance and negativity. Salespeople might make one sale out of 20 attempts. Anyone in a medical profession is under extreme pressure to not make a mistake (and sometimes things go wrong even when you do everything right).
There are very few professions who don't have to deal with the whole "focusing on the negative" thing (I can't actually think of any). It's pretty much a fact of life that if you want quality, you have to systematically eliminate your weak spots.
Salespeople make the sale sometimes. A doctor sees someone walk back in for their checkup who couldn't walk a week ago. A technical support person often says goodbye to a cheerful happy customer. Musicians may have to deal with criticism in the papers, but if they delist their phone number it's because of the fans, generally, not the critics. Actually that goes for almost all the creative industries.
Developers have very little positive to go off of, and few professions have customers as discerning and grumpy as compilers.
I wouldn't claim it's utterly unique, and everybody's got their own problems. But I don't think it's healthy or a good idea to ignore the problems we face because some people sometimes in some particular way have things even worse.
This is one of those cases where I wish we could all walk a mile in each other's shoes.
I can program. I am not "a" programmer. I've written a Ruby Gem or two, and I've even had some (very) small contributions accepted to widely used gems. I am really a project manager, but I recongize the value of understanding the tools that are used to build the projects I oversee.
I can sell. I am not "a" salesman. I'm a good listener. I'm able to establish positive relationships relatively quickly. After meetings, I receive positive feedback from customers We're a small company, so I often end up sitting in on sales meetings. I find it's valuable to have a first-hand view in what customer objections are.
I've walked a mile in both sets of shoes. I can tell you, unquestionably, that both careers can be equally frustrating. It's easy to center your world view around your own challenges, but to believe that yours are unique and more important than others crosses the line to narcissism.
Sales people have it plenty rough. Not only are they constantly hammered by objections from customers, but any time they take those items back to the development team, they're met with similar apprehension about adding to the backlog.
> But I don't think it's healthy or a good idea to ignore the problems we face because some people sometimes in some particular way have things even worse.
Who suggested that we ignore the problems? The important part about recognizing someone else's challenges is that we should seek to support each other in both directions.
And if you're a programmer, sometimes you fix the big bug that a huge sale depends on, and sometimes you create a feature that your customers love.
And, I take it you've never ever been in sales.
What many companies do is put everyone's name on a board, and everyone's sales are complete public knowledge. Every time you make a sale, you walk up the board and add another tick to your column. It's a way to shame people into not being the worst salesperson in the company. And at the end of the month/quarter, you start all over again. My closest friend as well as my cousin went through this process, and quit after a couple of years of having their self-esteem completely trampled upon.
> Developers have very little positive to go off of
I don't know that I agree. Red, Green, Refactor. That continuous moment of hitting green. Every time you solve that problem. Every time you strike a bug off the list. There are so many measurable accomplishments programmers make.
You think this:
"Developers have very little positive to go off of, and few professions have customers as discerning and grumpy as compilers."
Yet you mentioned this example:
"A doctor sees someone walk back in for their checkup who couldn't walk a week ago."
Is not seeing a product in action, one that possibly effects millions of lives (to be more realistic lets say 1000s, hell even a few dozen should be satisfying) in a positive way not very satisfying? I doctor helping a patient might not be as personal, but when I think about software I right the people who are using it and enjoying it are not far from my mind.
Unfortunately, many developers don't get a lot of opportunities to see their product in action. If you work on some public-facing service like Google or Facebook, you'll get to see your code being used. But if you work on a product that big companies deploy on their internal networks to improve their productivity, you won't see much of it.
Not really. I have been developer of VoIP application for about one an a half year and our clients only call us when they have a problem. Conectivity problems, delays in the audio when doing calls (due codec errors), problems with NAT, problems with the voice mails, etc... If everything is fine you just see no errors on logs and a beautiful graph expressing the increase of number of calls every month. Anything else.
Same when I was working generating telephonic bills for the clients. You will only have feedback if something went wrong.
Is that satisfaying? For my its enough; if the work have been done fine and the clients are reporting (almost) any error, I'm happy with that.
I couldn't disagree with you more, it seems to come from a pervasive cynicism that is day in day out grind of defect-finding in the programming industry.
How you can you casually claim technical support person has a more positive work environment than a programmer because sometimes a customer is happy when their problem is solved? What about all the customers who are irrationally angry even when you do your best to solve their problem? What about the problems you have no power to solve but have to take the heat for? What about the general prevailing attitude of frustration and discontent that characterizes the average person reaching out to support?
I don't understand how anyone could for one second say this is preferable to seeing a compiler error. There's no negative emotion inherent in a bug you discover. The fact that you are looking for flaws and fixing them is "negative" in a technical sense, but I find it bizarre to compare it so unfavorably to real negative human emotion directed at you. Even when other people are critiquing your work or sending you bug reports, there tends to be less emotion and more constructive feedback than you get in a service industry.
And what of citing "creative industries" and then drawing a sharp contrast to developers. Software engineering is extremely creative. The positive feedback from development is primarily the joy of creating working software. I've been doing this 20 years and it's still a thrill. Furthermore, I get plenty of positive feedback for my work. Obviously it's not on the scale of the insane hours I've spent in the trenches obsessing over minute details, but that's fine, I can take a compliment and find it gratifying even if it's shallow and uninformed of the true scope of my work.
I think there is definitely something about programming that leads to a pedantic mindset that could be offputting to others, but I think it's nonsense that it leads you to be inherently negative. Programming for me is empowering, attention to detail is just how I hone that power.
You make great points, and I agree with everything except: systematically eliminate your weak spots.
Sometimes that is what you need to do. But sometimes you are better off further enhancing your strengths to real excellence rather than bringing up your weaknesses to an acceptable level.
Sometimes you can really sell your strengths, the things that make you stand out, and then work around the weaknesses by focusing on projects where they don't matter or by hiring an assistant/partner that can handle the areas you are weak in.
You should draw a clear line between those professions. All of them are "producing" professions, but the first group (artists, writers, musicians) do not have to maintain the technical responsibility that the latter (engineers, carpenters, programmers) has to.
This _technical responsibility_ brings a lot of the "negative" said on the article; actually, that's not "negative" it is "not good enough".
There is not a discrete "brokenness" to things like art or music. What you ship works or it doesn't work. Nobody knows or cares about the mountains you moved to produce what you did, they only care about the parts that don't work.
Some industries are absolutely comparable, but a much smaller number than I think you're implying.
The sysadmin cycle of life is to get hired then spend several years fixing, consolidating and automating until someone decides they don't need to keep paying a sysadmin "for nothing".
I'm not a sysadmin but I ended up looking after the office network and you are 100% right about this. Not only that, by the time you know someone has a problem, they're already annoyed, at you, for no good reason. More often than not, it's their own fault.
The other day someone was complaining that the internet was slow (it was), turned out they were syncing dropbox, backblaze and icloud, saturating the network. I understand now why sysadmins lock down everything where they can :)
Thats kinda true actually :-) I am actually a coder by heart and moved now into a sys admin job. I kinda like it because once everything is nicely automated I did my work :-)
This is one reason I'd much rather be discovery-oriented than goal-oriented.
If you look at all of these as just part of achieving your goal, then all of these are negatives. The compiler prevents you from achieving things, your bug reports remind you how you haven't achieved them, every missed deadline makes you wonder if you'll ever achieve them, and your customers don't appreciate it when you do achieve them.
But if you look at all of this as a process of discovering what customers want and how to accomplish that, all of those negatives become positives. Your compiler error tells you early about something that would've become a problem later on. Your bug report reminds you of a case you haven't handled, some subtlety of the problem that you're just now learning about. Your missed deadlines mean that you didn't know enough about the project to estimate accurately before, so now you have more information about its true scope. And your unhappy customers will tell you ways in which you can improve.
I reckon it depends on the size of the company you work for too. Obviously there will be always some errors and problems but there is also quite a lot of thinking and creative work to be done. Especially if the team is not massive and you take part in decision making process. Not exactly the "turn this coffee into code" type of job.
My friend working in a oil industry/software company (quite big) told me once - here you only get noticed when you manage to screw up something.
> I find myself wondering how adaptation is even possible.
I've been doing this job for 7 years now, and I've wondering along these lines a lot more lately, because I honestly do like what I'm doing and I plan do it for another 7-10-20 years. My current best answer is "don't take anything personal".
Yes, the latest bug will always be something that would risk taking us all one step closer to Armageddon, or so the clients/non-IT-colleagues would like to make us programmers think, but whenever I'm put into this position ("the world is crushing! do something!") I try to chill it down before taking action.
Also, there are always, always harder things in life than being a programmer, I try to remind me of this whenever I can. Just this summer I went out to help my grandma' pick up plumes during a weekend. A peasant, she's in her mid 80s now, she hasn't had a day of "vacation" or "paid holiday" since she married grandpa', 60+ years ago. One of her biggest regrets that she's experiencing right now is that she hasn't the physical strength anymore to work as much as she did for each day of her adult life.
Try working in support for a while. Customers only call when something isn't working the way they expect, and since documentation is usually and afterthought among development teams, figuring out what is really possible with the software is often difficult. When you do identify bugs, you often have to go back to the customer to tell them it's not going to be fixed - and take the abuse that comes with those messages. Let's not even talk about non-technical salespeople who may not really know what the product is capable of and either tell customers wrong things or outright lie about what the product can do to make a sale. At which point, once again, the problems end up in the laps of support engineers.
I get what he's saying, but I think he answered it himself, when he questioned if he was being overly dramatic. He is being really over-dramatic.
I would love to hear about any occupation where the negatives aren't run into in a similar way that he describes programming.
That being said, the one thing that I dislike about programmers in general is that I think we believe we sound smarter if we figure out ways how an idea won't work. It's annoying when you come up with a new idea, and all you hear is a litany of reasons why it won't work.
The most important lesson I learned was soon after I had moved to the Valley, and I gave a suggestion to one of the senior engineers. Instead of shooting it down immediately like others loved doing, he simply said something like "Okay, I'm not sold on it but give it a shot." I had been prepared for a lengthy argument over why my idea was good, and I was taken aback at his immediate open-mindedness. It's something I've taken to heart since then.
The mindset between engineers looking at new ideas and resolving old ones are different. A good engineer with foresight can see when an idea or proposal is good but at the same time he's thinking of the challenges it poses. I know I do this daily and the linked post is actually pretty hard hitting for me.
When I was looking for new work everywhere I applied I looked at how beneficial it was for me but that was always balanced with questions about how it will shape my career and if it will take me to a place I want to see myself in 5 years or will it put me 5 years behind my ultimate career goals? No matter what company or person I talked to I managed to find the reasons why it might not be beneficial to me.
I spoke with my girlfriend a lot during this search. At one point she got fed up with me and said to "shut up and stop being so negative". It sort of offended me because in a sense I didn't feel that I was being negative but rather "just looking at it from all angles". The coder mindset reaches into our daily lives where we start weighing the pros and cons of every decision to figure if it is worth the effort instead of just enjoying things.
Of course, I may not be typical. I live in an area with very few hackers and engineers so its hard to compare myself outside of these forums.
I'm not sure that specifying how things won't work is done to appear superior rather than giving feedback. There probably isn't enough time in a day to try everything and if you can save some time by pointing out why something won't work off the bat it's probably a good thing.
As with everything though, it kind of comes down to how you communicate that something won't work.
It also comes down to being right about it. It's often much easier to write something off ("that won't work"), than to accurately assess the reasons why it may not work, and possibly be part of modifying it so that it will. That difference is also subtle (just as subtle as the presentation in many cases), but also very important.
I like this point. In one company I was told a couple of times that things I suggested couldn't be done. I got a raise by going off and making a proof of concept that it could be done.
With that said, identifying challenges that need to be overcome ahead of time can be a useful step in planning as long as its not always seen as a reason to do a full stop on thinking about the concept.
There is nothing intrinsically negative about anything said here, just neutral things viewed in an extremely negative lens. Here's the exact same set of steps making up the "normal workflow", but framed as a positive feedback loop:
1. write some code
2. run the code
3. get further than you did before (perhaps with a new error message)
4. decide what's next and go back to step 1
I don't think negativity is intrinsic to the profession. I get to build things every day. I get to fix problems. That's an incredibly satisfying and positive thing.
That reminds me of an old story about how different people can look at the same job in different ways:
A man came across three masons who were working at chipping chunks of granite from large blocks. The first seemed unhappy at his job, chipping away and frequently looking at his watch. When the man asked what it was that he was doing, the first mason responded, rather curtly, "I’m hammering this stupid rock, and I can't wait 'til 5 when I can go home."
A second mason, seemingly more interested in his work, was hammering diligently and when asked what it was that he was doing, answered, "Well, I'm molding this block of rock so that it can be used with others to construct a wall. It's not bad work, but I'll sure be glad when it's done."
A third mason was hammering at his block fervently, taking time to stand back and admire his work. He chipped off small pieces until he was satisfied that it was the best he could do. When he was questioned about his work he stopped, gazed skyward and proudly proclaimed, "I'm building a cathedral!"
But this isn't what the piece describes. The author is talking about the _feedback_ one receives while doing work. Take the 3rd mason and start giving him a list of what's wrong with the work he's doing every day until the cathedral is built, and see what happens. This stonemason example, while touching and certainly applicable to some situations, is just too far removed from the reality of what many programmers experience to be relevant here.
I was addressing what the parent comment (from peeters) insightfully observed about the original article's four-step workflow description: getting to the next bug and fixing it could either be thought of negatively ("damn, I have another bug in my code") or positively ("I've solved this problem and made some forward progress"). Whether you find this negative or positive is a function of your mental state.
This is analogous to the mason's iterative workflow: noticing that his stone doesn't yet fit quite right and chipping a bit more off the side until it fits perfectly.
During development, most of our daily feedback comes from the code itself, not from people yelling at us about how broken it is (although that does happen sometimes).
The author explicitly says that fixing bugs feels good. But the point (as I see it) is that the workflow often obscures the larger positive goals of the endeavor and tends to burn people out, and that's a net negative. You can argue that it shouldn't, but I don't think you can argue that it doesn't.
Everyone wants to be that 3rd happy mason. But that story doesn't tell you how to do that, it just suggests that it's a better way. Saying that it's just a function of your mental state is tautological.
The story tells you explicitly. Don't stare at your watch, think about the product vision.
Every day I go to work to fend off spies who want to steal your data. Protecting the powerless, defending your freedom! I will never meet you, and I will never even look at the treasure I am defending, and most of time is spent fixing broken configs, but I am doing it for a good cause, and at the end of the month I enjoy my paycheck too.
>Take the 3rd mason and start giving him a list of what's wrong with the work he's doing every day until the cathedral is built, and see what happens
Even the smartest people I know write imperfect/buggy code, especially the first time around. If you don't take it personally - as you shouldn't - I don't see the issue.
I don't understand the issue either. A compiler warning or exception report is immediate and precise feedback. What could be easier to deal with impartially?
The bigger picture of course is that criticism, whether it comes from other humans, machines, or oneself, is the only way to improve anything. If you want to create anything worthwhile you have to have some mechanism to improve. Why would we want to bury our heads in the sand just so that we never have to hear a critique?
I suppose you could get a rote job on an assembly line and spend your free time watching TV and you'd never have to hear another complaint, but that sounds like an absolutely miserable life to me.
Yes, feedback is helpful and you shouldn't take criticism personally. No disagreement. But feedback that's mostly focused on small problems is draining and criticism is draining. If that's not the case for you, awesome. It's the case for some people. Try to empathize with them. The article articulates that draining feeling and I find that pretty insightful and useful.
It's an old story that probably pre-dates programming and I've seen it several times in different places. I have no idea what the actual origin is. I just searched the web for "I'm building a cathedral" and used the wording I found here:
This brings up an interesting concept. All great creators (artists, programmers, woodworkers, hairdressers, etc) tend to be more pessimistic than optimistic. If you attitude is "Wow this program I wrote is totally awesome, I deserve a pat on the back", then you'll never improve upon your program and you'll end up never improving your skills and will end up a rosh katan[1]. You have to be the kind of person who sees each of your creation in a constant state of less than perfect in order for you to act upon making it better.
Interestingly enough, people on the other end of the spectrum (sales people, executives, marketing people, etc) have to be the opposite. You can't have any doubts about the awesomeness of the product. Doing so would be counterproductive.
Among all the non-programmers I've talked to about work, I've never found one who doesn't have to deal with some sort of constant, repetitive negative feedback. Teachers have to deal with some kids that simply won't stop acting out, and who continually perform poorly on assignments (not to mention parents happy to tell them everything that the teacher is doing wrong). The salespeople have countless deals they fail to close. The manager has to make painful decisions about other peoples' livelihoods, and absorb the criticisms coming down from higher up the chain. The artist has to deal with everyone being a critic, and doesn't have the luxury of dealing with things that either work or don't work, it's all subjective. The doctor can't cure everyone. The lawyer can't get justice for everybody. The data-entry clerk peon has to ignore that they're completely replaceable and that they'll probably be replaced by a computer sooner or later. Anyone building anything (not just software) has to deal with the reality that 95% of the time, it's not done yet, and you still have more work to do and things to fix.
That's not to say that some people aren't going to be happier in certain fields than others, or that some subsets of the field fit some mindsets better than others, but software is pretty good work. The article acknowledges this right up front, and then ignores that to dwell on the negatives. It blew my mind a little to see such a negative perspective. If I fix a simple bug in my code, it doesn't bother me much, because I know I sometimes make mistakes. If I find and fix a really interesting subtle thing, then it means I learned something new, and that the product is now in better shape than it was yesterday. If there's a usability issue, it's an opportunity to figure out a new way to do it. And all the while I have the constant positive feedback of knowing that this thing that I built is doing something, I can directly watch it do that thing, and that it's being used by people to get stuff done.
Unless you build everything exactly right the first time, and never have to deal with external changes that mean the software needs to change, you're never going to be free of negative feedback. So you should start looking at why you're letting the negative parts drive your attitude.
EDIT: My own personal idiosyncrasy is that I get very suspicious, maybe even paranoid, about a complex task if everything seems to work right the first time and I don't have a few cycles of negative feedback. I know it's complex, and so I don't expect perfection out of the gate, so a few runs through the "fix one thing, find another issue" washer are oddly reassuring to me. Even though rationally I know that fixing things I knew to test for doesn't mean it's any less likely that there are errors in the things I haven't thought to test.
I agree. I thought about going into academia for a while, and started on a Ph.D programme, but then realised that a large chunk of my life would be spent explaining the basics of the subject over and over again to people who may not necessarily be as passionate or excited about it as they could be.
I sort of realised eventually that given how expensive going to university is now (9x more expensive than when I went), I'm not necessarily going to be teaching the brightest and best. Instead, I'll be teaching the brightest and the best who also have the willingness to get massively in debt and/or who have rich parents willing to pay for it all. Suddenly, the important moral purpose disappears, and you are left with: well, I could get paid the same amount in about five years time as I get paid now to write code. Why do I want to do this?
And I kind of like software as an industry. It's not perfect: there's douchebags and posers and so on. But it's reasonably recession-proof, it's not on a doomed-path-to-hell like lots of industries, it often lets me work on quite interesting problems (often having some satisfaction doing it), most of the people are pretty nice, the bureaucracy is minimal (for me anyway) and the pay is decent. The main downsides: RSI and those nagging calls from my parents about how Google Fireface isn't talking to their printer. The latter is a trivial problem and the former is mostly fixable by posture adjustment and exercise.
Maybe it's just me but I've always seen these things as positive feedback loops. I write a failing test so that I have a guide as to what to do next. I fix a bug so that my app does a better job for my user. I'm not sure where his negative attitude comes from, maybe he likes to believe he can write perfect software and takes it at as a personal failure when he gets a bug report? Personally I find coding therapeutic, at the end of every day I know that the product I'm working is a little bit better than it was yesterday.
I agree with you. I feel like this article is pretty melodramatic. I've been a (professional) programmer for the better part of 10 years and I've had my share of ups and downs, but this job is definitely a very, very good one. The sheer amount of freedom we get from a) the good pay and b) the fact that programmers are so in-demand right now that companies bend over backward for us really can't be matched in many other jobs.
The lamenting in this article is from somebody with very little perspective on what most people have to do just to survive.
I think these are two different things. It can still be a nice job to have, even if the process is broken. Writing reliable code is hard, probably harder than it should be. Just look at the amount of software with security holes[0] and/or performance issues.
I have to agree with you. In so many careers your performance is subjective. The cool thing about programming, to me, is that when there's something wrong, it's objectively wrong, meaning it can be fixed. Sure you might be able to 'fix' things more quickly or less quickly than someone else, or implement a solution better or worse. But the product you create pretty much either works or doesn't work.
Perhaps it's a matter of expectations. No one expects a salesman/woman to close 100% deals or even 50%,a manager's job is pretty well known, and the stress associated with it is taken care of from the start. Lawyers get paid whether they get justice or not most of the time, data-entry clerks have jobs that end at the end of the day, and they won't be thinking about a product they coded that might have some critical flow and come back to bite them months after the release.
If I remember well teachers and medical staff have depression and other work related mental issues rates on par with programmers, so you would be right about the negativity they also face everyday.
Of course it's not the end of the world, it's just something that is not brought on the table so often I think.
I think part of the reason the article is negative is that in much of the industry it's not you building anything, but it's you fixing some garbage that was hacked on by an army of a thousand morons before you into something that isn't really fixable into what management wants.
All the while dealing with people around you who do not understand what you do, whatsoever. This last part is crucial and it is everywhere. I have yet to meet someone who is not an engineer or ex-engineer who actually understands what I do and what I have to deal with not only with my own code (which is far from perfect) let alone code written by some overseas contractor who just got his copy of Java for Dummies so he can learn PHP.
It's times like these I'm thankful for a life lesson I was taught about 4 years ago.
I'm not a professional coder, but I do a significant amount of hacking and coding for one of my research fields (Computational Economics). I noticed this cycle too--this cycle of focusing on the negatives. It really did bring me down.
I chatted with my adviser, who was married for a number of years to a child psychologist. She recommended to him that every time he accomplishes something small, get up and walk around. Do something small to reward yourself. Then, get back to coding. This inserts a positive stimuli in an otherwise negative feedback loop. The more bugs you solve, the happier you are.
I've found this to be very helpful for me. Hope if helps some of y'all too.
My partner and I just had our first iOS game approved. We had to ship without a bunch of features we had planned for (e.g. non-English localizations) simply because we ran out of time. During the final stages of the project, we thought we'd like to do something like a web-comic, to share the human story behind the development of the game. Now that the game is approved and we're reviewing our notes and drawing the comic (it can be loaded dynamically into the game as a slideshow, and it will also go into our facebook page/company blog at http://noisytyping.com), our view has shifted from 'we could have done better' to being very pleased about the whole journey: how we started out, what challenges we faced (automating level-generation was one) and how we managed to stick to our plan and ship it. Without the postmortem, we'd probably never be motivated to make a game again.
I went to a tradeshow for my company a few weeks ago, where I got to just interact with potential customers all day. I had an absolute blast, by the end of the day where the other folks on the team were tired and ready to leave (I was the only developer), I was pumped and already thinking of how to come across even better to clients at the next day of the show. It made me realize how programming has adversely affected my demeanor and way I interact with people.
I realized that not so long ago, I was actually outgoing and cheerful most of the time, but programming has made me more surly and sometimes reactive in an insidious way. With programming you're always dealing with problems, and if you're not solving them in code, or being infuriated by something that you thought would take 30 mins but has blown your entire day, you're dealing with people problems.
"Why isn't this done?", "Why should we pay that much?", "When is it going to be done?", "How long do you think its going to take?", "Why is it going to take that long?", "Can you just squeeze this one thing into the iteration?", "That sounds easy", "Why is this broken?", "Who broke it", "Why can't you just code", "You ask too many questions" ... aaaaaack.
its just this steady barrage of crap you have to deal and you're usually the one saying "no", "we can't do that", "Why do you want to do that?" to where you just become this proxy for negativity even if you don't want to be, because ultimately you're going to be the guy cleaning up the shit when everything explodes because nobody thought to figure out how to do the whole thing properly.
Unless you're working at a real top notch engineering place, where half these questions don't come up or the top brass understand how the whole thing works, it can really mess with your attitude.
When I had that epiphany after the tradeshow, it really freaked me out to realize how professional programming was changing my attitude to people and life, so I don't think I'll be doing 100% development for much longer.
Hour by hour, day after day, I do this. Always searching for what's wrong with what I'm creating, rarely thinking about what's good about it. It's a negative reinforcement feedback loop.
"Dude, you're so lucky to be a master sculptor. Always hanging out with famous models and actors who want nothing more than to strip for you. Your works will be celebrated for more than two thousand years. I wish I could do that."
"Actually being a sculptor is making me pretty miserable."
"Woah, dude. What do you mean?"
"Hour by hour, day after day, I do this. Always searching for pieces of stone that don't belong, always trying to remove the elements that aren't part of my work, rather than being able to focus on the stone that remains. I can never truly build anything, only erode. It's a negative reinforcement feedback loop. I think I'll try watercolors next."
This guy has not discovered what it means to be a programmer, he is simply in a phase of his programming life. Chasing down bugs all the time? Why? I don't do this, and when I run across a bug it is usually a quick fix and not a big deal.
The goal is not to write it perfectly without bugs. The goal is to release it perfectly without bugs, and to do this all you have to do is test your code often as you make changes to it. (alt tab || cmd tab is your best friend)
Now, if you are running into bugs that take you 4+ hours to resolve, you simply have not been programming long enough. Over time these will be trivial issues for you.
What is amazing about being a programmer is the ability to create amazing things. Being a programmer is not awesome because writing conditionals and for loops are badass.
> Now, if you are running into bugs that take you 4+ hours to resolve, you simply have not been programming long enough.
I'm sorry, but that statement is untrue; there is no generalization for the term "bug". They can be as simple as "your borders on this web page are misaligned" to a subtle memory leak that can only be reproduced on a small fraction of users' systems. Or maybe the bug is a fundamental design flaw that requires rethinking the entire project (oops).
Now how often do you run into these subtle memory leaks? How often do you run into fundamental design flaws? Once, twice a year?
If it happens so rarely, which for most developers I believe it does, why would you allow it to get you so jaded? Why would it be apart of your daily concerns or something you felt you needed to prepare for?
This depends heavily on the legacy of the codebase you are working with, I imagine. I'm thankful that I (nearly?) never run into serious design flaws, because the people that built this code before me did a really good job. I could easily imagine a worst-case scenario where the code you're maintaining was written by a stream of interns, implementing requirements written by committee, over the space of a dozen years. Fundamental design flaws might be so ingrained, and the codebase so large, that you could not easily refactor it into something nicer.
This is true, but if you are working on such a large code base, and you like the company you work for, you will be working on it for a long time. You will become familiar with the coding style (or lack of style) of the original programmers, and you will be able to recognize their mistakes quicker over time.
Rewriting it is always on option, maybe not the correct one, but it is an option. But probably better is to figure out how to rewrite it in pieces.
If you are working with a legacy coldfusion or php code base, god help you. But there are still ways to abstract the original code to allow you to implement a more gradual/iterative code rewrite strat.
Sounds like you've never been tasked with working on a huge base of code you'd never seen before. If all I ever did was work on code I wrote, I could see myself thinking like you do.
This is not the case for a lot of people. Maybe in this HN startup bubble, but not in the "real world" of software engineering.
That is a good point, but I do have the perspective you talk about. I started out at a web shop for 4 years, so I'd spend a lot of time in other peoples code. I then moved on to a nice little SaaS company with a 10 year old code base which had a bunch of legacy code that I had to deal with when first starting out. I had to pick up a variety of languages that I had not used professionally before. I have spent 4 years there and am leaving at the end of this week to start my first company.
But my belief is the same, the solution to the problems described in the article is time/experience, not the adoption of some pessimistic mindset. You will run into bugs when working in other peoples code, as a result you will learn not to make those mistakes. Over time you will get quicker at identifying similar bugs and will be able to resolve them quicker each time as well.
The most common answer to any CS question that you are asked in college is "It depends". So how do you resolve these nasty legacy code bugs? Well, it depends. Is this code reused a lot in other places? Is this critical functionality to the user? Once you determine how important the buggy code is, you can decide whether to solve it with a hack or a well thought out solution.
Don't sweat the bugs, don't become a Debby Downer, fix them as they rise, and keep building cool shit.
>if you are running into bugs that take you 4+ hours to resolve, you simply have not been programming long enough.
Firefox had a memory leak that took years to track down and eliminate, so according to your logic Firefox does not have any employees that have been programming long enough.
Well, I was speaking generally when I wrote that. I probably should have put in the word frequently to be more specific. I did not mean to imply that one day you will reach a point where you will never battle with a bug for over 4 hours again! But in my defense, I did write run into bugs and not bug.
Well, sure, but everything in life is a "phase." A whole career might be a phase. But that's not the point. This post clarifies a vague problem. It's great that you've avoided that. Good for you! Seriously. But to say that he hasn't "discovered what it means to be a programmer" isn't helpful:
Someone doesn't feel amazing about being a programmer.
Programming is amazing.
Therefore that person is not (yet) a programmer.
And the "(yet)" is unimportant here, because a negative feedback loop is exactly what gets in the way of experiencing the amazing part.
The point isn't really to define what a programmer is, it's to define a problem that many people who work as programmers experience, and how that contrasts with other people's expectations.
I think I may have misrepresented myself. I have not avoided the buggy hell described above. I have lived through it. My point is, his problems are temporary and expected for anyone that cares to better themselves. So it is perfectly natural for him to be upset about it, and his emotions are valid.
What is dangerous is he is currently leaning towards the idea that to be a good programmer you must be pessimistic, always afraid of the all the crazy unknowns that might happen. This is wrong, there are techniques to avoid these problems that will naturally become part of his programming style over time. No need to be a pessimist, no need to be afraid. Just keep on plugging away and one day he will wake up and think, its weird that programming does not feel like I'm pushing a rock up a hill anymore.
Edit: Also I never said he was not a programmer, I said he didn't yet understand what it means to be one. We all go through this, and he will realize it eventually. I just hope he doesn't end up as jaded as his article assumes he will.
I know, but I think the way you were talking about it brought "what it means to be a programmer" into line with working as a programmer generally. He's talking about how a pessimistic feeling about being a programmer arises. But I think you're essentially saying: just avoid that problem and it'll work out. That train has left the station.
You say "no need to be a pessimist" but I don't think that's what's going on at all. If you encountered a bug in a program, you wouldn't say "oh, program, don't be so pessimistic, just keep running and you'll be fine!" He's diagnosing the problem, not declaring that it's insurmountable on a case-by-case basis. I don't think that's dangerous, I think it's appropriate. When you see the feedback loop more clearly, you can deal with it. Ok, that might mean pushing through to a better place (if one believes that will work for everyone, as it has worked for you) or it might mean finding a different career.
I just don't think your description of waking up one day and feeling that things have gotten easier squares with what a lot of us experience. Things do not always get much easier just because you keep going, or because you try one thing after another. Sometimes the work gets much more rewarding, for some people, but you can also burn out before you reach 10,000 hours, and it's not reasonable to say that people should simply figure out how not to burn out. To pin that all on a pessimistic attitude is trivializing a non-trivial problem.
For the record, it's clear to me that you're speaking from a sincere desire to share what's worked for you (including a bunch of sound strategies for addressing problems as they arise) with other people. That's super cool. I just want to defend the idea that there's more to breaking the bigger cycle of drain/burnout described here than choosing to think positively.
I'd like to start off by saying thanks for for holding my feet to the fire on this one. It has forced me to rethink what I have written which is almost always a good thing, and in this case I believe it to be good.
What you have made clear to me is that I made a mistake in my interpretation of the OPs post. I had incorrectly assumed that he believed that to become a good programmer that you had to be pessimistic.
What he actually said was (not quoted) in order to be a good programmer he needed to adopt a certain mindset, which was to focus on the negatives. He believes this mindset is slowly making him unhappy because it is constantly reminding him of all the mistakes he made throughout the day, every work day, of every year.
I did overgeneralize his problem, and that was my mistake. I still contend that his problem is temporary and that he should not worry about it as it is a natural part of growing as a developer.
After reading his post a second time I realized something. He doesn't just think of tracking down bugs as focusing on the negatives, but he considers the bugs to be an actual list of his failures. Any bug to him is a failure at any point in development. No wonder he is upset. What is a bug to you? To me a bug in the wild is a huge, huge embarrassment. I feel just awful when one sneaks by. But a bug caught in development is nothing more than a logical typo. If you are a writer and you publish an article incorrectly switching you're with your, or their with there, you would feel dumb. But if it happened while you are burning through your first draft? Is this a failure? No just a minor mistake that you can resolve relatively quickly.
The solution to feeling bad about bugs is not to think positively about bugs, but simply not to worry about them. They will happen, you will catch them, and you will get better. I'd like to elaborate more on how doing nothing will fix the problem. I will probably do so tomorrow even though these comments will probably be dead. Thanks for going back and forth with me, it was fun.
> This guy has not discovered what it means to be a programmer, he is simply in a phase of his programming life.
Very well put. I see so many posts here that I roll my eyes over. This is not to put them down, may be it has to do with the fact that we as programmers don't talk about our "feelings" :)
I'm glad you liked the comment :), but I do think it is good that he has shared his feelings. Whatever you can do to gain new perspectives and grow should be done. My hope is that after writing this article that he reads through all these comments and realizes his future is much brighter than he currently believes it to be. And that all the frustrations that he is experiencing are temporary and will quite quickly go away.
Instead of negatives, you're looking for positives. At the end you're rewarded with nicer code than you started with and green lights all the way down.
It's all about how you frame it - why would you frame the activity you spend most of your life doing negatively?
No, you GOTO 1, and write new tests that match better. Just because you have a dysfunctional organization that doesn't let QA and development talk doesn't mean that's how it has to be.
The question is not "What's wrong with this?" The proper question is "How can I make this better?" He's adopted a negative mindset by choice, whether he realizes it or not. That's not even what really grinds my gears about this post.
The really bad part of this post is the implication that this mentality (whether one takes the author's negative point of view, or my slightly more positive interpretation) is endemic to software development. It's not. Asking the question, "How can I make this better," ought to be a fundamental part of one's daily routine. Had the author adopted this mentality in general, he might have noticed a flaw in his workflow:
1. Write some code
2. Run the code
3. Get an error message
4. Find the error and back to step 1
There are some critical steps missing. A more appropriate approach would be:
0. Think about what I'm building
1. Write some code
2. Run (Test) the code
3. Get an error (of some sort)
3.5 Think about what might have gone wrong and verify it
4. Go to step zero.
That's right, when you find an error there are two distinct thought processes involved. First you think about what might have gone wrong. This would be the forming a hypothesis step of the scientific method (I've lumped testing into step 3.5 so as not to stray too far from the author's initial workflow, but suffice it to say that testing should be a recursive call to this entire process). Once you've discovered the source of the error, it's time to consider how best to fix it. Yes, more thinking. Only then should one go back to writing production code.
Sadly, I don't think the author's method is that rare. I had a professor who referred to the write/run/test/fix method as the original genetic programming. I think that's a fair statement. The problem with this method is that one ends up with a system that may work, but with no deep understanding of why it works. Absent that understanding, it will be more difficult to improve (fix) the system.
God help the next poor soul (aka the author in six months) to work on the system. Therein lies the negative feedback loop.
I think one way to help fix this negative feedback loop is to use the advice of the Harvard Business Review's article "How Customers Can Rally Your Troops" (src: http://hbr.org/2011/06/how-customers-can-rally-your-troops/a... ). The premise is that consistently showing your employees proof of the positive effects your organization's products produce for end-users can drastically improve motivation. I just linked to the abstract, but the full article goes into the dramatic effects this technique had on a university fundraising call center (a job with constant negative reinforcement).
Positive feedback is definitely important. As developers, we very frequently hear about things that have gone wrong but we're only rarely told about how what we did resulted in success for the company.
After being a programmer for 20 years, I never thought of it that way. I think it is one of the better jobs out there, and I've always considered myself fortunate to be able to make a living that way. I will say, however, that spending the last 5 years working as at technology director at a school has been more rewarding, but it is not so much the kind of work I'm doing, but that I really value this school and the work they do. I feel privileged to be a part of it. In fact, the most difficult thing I dealt with in my programming career was not the work of programming, but working for companies where I did not always believe in the product.
Yea I got over that. Shit happens. Don't sweat the small stuff, yada yada yada. Besides when you fix it everyone lights up. It's the closest thing I've seen to a performer doing some amazing stunt with me being the amazing person. Focus on that, and not so much on that it broke. The difference between developers and non-devs is we can fix it, and that's really cool power. This article is almost like Wolverine complaining about his super powers being lame and always having to save the day. YOU'RE WOLVERINE STFU!
I think after being a programmer I have changed my outlook for the better because I realize what's possible instead of being trapped by other people's ideas/mistakes. I see how things are connected and if I changed this or that how it changes our limitations. Anyone can say "What if" very few can "Here's how." And that is really empowering and liberating.
I suppose when I was younger I was negative I wanted everything to be perfect like it couldn't be, but as I matured I see bugs, missing features, bad design as just opportunities and not the end of the world. Being late, bugs, complaining users, whatever it just doesn't bother me.
I'm not tuning them out just choosing to listen to what's really important and cutting through the bull because I expect all of it to happen. We're late ok I'll work a little more realizing I can really only make it about 10% faster, there bugs give me a reproducible test case and I'll fix it, users bitching reach out to them personally and find out what's the real problem.
And just like anything else in life, whether it's programming, football, music, or ditch digging, your attitude is your choice. The difference came when I chose to be positive...and laugh a lot more at all of the irony, bad choices we make, and gotchas that always creep up. Laughing really helps.
I have a very intelligent friend who try as he might cannot learn programming. He has interests all over the academic board and teaches two unrelated courses. I think I understand now why he cannot. He's an eternal optimist. I tell him he's selectively ADD about programming, but maybe he's just allergic to the negativity of it all.
I've been through this myself. I realised that the problem was me, and the projects that I was working on. I was fortunate enough to be able to step away, then go and find work that IS rewarding (for me it's playing with the front end, where people play with the app and go "ooooh!" and "aaaah!").
The key for me was to document the things that I hated about the job, and avoid them at all costs, but to acknowledge that criticism is something that feeds back into an application improvement process. ie. Don't take it as personal that someone is criticising you/your work. Find methods of improving the communication channel so that you don't spend days/weeks coding only to find "that's not what I wanted! that sucks!"
I'm fortunate to have an ex hacker/programmer as my manager who knows/understands/addresses my needs very well in my current role.
At some point I stopped chasing the higher paycheck, because I recognised that with a higher paycheck comes higher expectations, demands, hardships. Look at it from the employer's perspective - "We could hire 2 graduates at your cost, at that rate we expect you to not make mistakes, and to get twice the amount of work done."
A friend earns almost twice as much as me, with similar years of experience, but he is expected to miss lunch, stay back until midnight, answer calls to China/India on a friday night. No please/thankyou/you're doing a great job. Just "do it".
What we have done and what happens to us all accumulates inside ourselves and becomes the basis of our future consciousness and state of mind. Peoples' minds and consciousnesses are comprised of energy. If we use the example of a lightbulb, the consciousness is most akin to an electrical wave produced by the generator and the mind is most analogous to the light radiated by the bulb.
If we work in such a way that produces high entropy codebases, hides problems instead of illuminating them, or produce (or have to work with) highly inter-braided (complicated) architecture with no way or occasion in which to improve matters, then it's easier for people to be caught by grudge at their employer, clients, or circumstance. People can be influenced by these bad circumstances to abandon themselves, and in doing so, their resultant ignorant behavior will make their mind mind become dark. This is a most dangerous circumstance for a human being to live in, so the task of the modern programmer is to find out what they have worth living for, to find a good self, and to protect themselves from wrong relationships and from destroying themselves (through loss of simplicity in one's life) such that they can effect their benefit for themselves and the world. Without individual awakening then it doesn't matter what profession they hold, they still can't guide their life properly. So the most important teaching for programmers to save their way of life is that they have to understand properly what life is, how great a teaching it is for us, and just how precious is the opportunity that we have been given through our lives as human beings.
Being wrong is fantastic. You simply have to come to appreciate it. Every time you learn that you are wrong - and this applies for everything in life, not just with programming - you never have to be wrong in that way ever again. Not for the rest of your life, if you can remember, will you be wrong in that particular way. How amazing is that?
You're not 'focusing on the negatives', you're getting to be wrong, a fantastic opportunity. Most people don't get to be wrong. They persist in their wrongness and swim about in a sea of mediocrity with no sense of personal advancement. To get to be wrong on a regular basis is nothing short of exciting. Sure, others will misunderstand it. Managers and business types will not understand why you simply couldn't do everything flawlessly from the start and they'll try to give you a hard time about it. But it doesn't really matter. No matter how hard they push you, they can't make you think. No one can. It has to be undertaken entirely under your own will. And when you do so and come up with something wrong - you know you are actually guiding yourself to develop rather than stagnate.
Go on, be wrong! And then never be wrong in that way ever again!
Apparently, I come off to some people as very pessimistic. I don't feel pessimistic but, as I programmer, I'm trained to focus on all the things that can go wrong and consider all the edge cases. This is a useful skill but can also be perceived as very negative even if that's not what I intend. Unfortunately, it's a skill that is also hard to turn off and ironically it's worse if I'm actually enthusiastic about something.
For myself personally I feel the positive of making progress, or implementing that new feature, by far over-weighs all the little bits of negativity and frustration of a bug or error. Even if that implementation isnt 100% correct, its still satisfying to see something happening which takes you another step towards the goal. Sure it can be pretty destroying to get stuck on that one main problem for a long time, unable to find a solution and with a million errors being thrown, but then when that problem is solved the positive feeling can be even larger anyway, depending of course.
I find it unrealistic to expect it to be any other way, youre an imperfect human trying to design something so complex, within an environment that has zero tolerances for mistakes. Hell, if you even accidently capitalize a single letter somewhere in thousands of lines of code, the whole things going to fall in a heap.
So I cant say I overly relate to the main attitude of the article, as much as I understand what its saying.
A quote from the article: "There's so much about programming that is incredibly satisfying and empowering. But it doesn't change the fact that, for me, programming builds an acutely negative mindset over time."
The author of these words seems to miss the fact that all systems that move from one state to another require "negative feedback", but the "negative" in "negative feedback" doesn't have the meaning he's giving it.
The author sees programming as emphasizing the fact that software is usually broken. I see programming as emphasizing the fact that that I can fix it, and once fixed, it remains fixed forever. Compare that to "fixing" relationships, or government, or nearly anything else one can name, all of which respond to your efforts by getting worse.
When viewed this way, programming is (like mathematics) an escape from a world in which efforts to solve problems are either ineffective or make the original problem worse. The fact that the end result might actually be useful to someone is frosting on the cake.
I really don't know about this. For every bug I fix, there's a time I run the code after a change and the change does just what it was supposed to do. For every time a client complains about something that doesn't quite work yet, there's a time she told me how happy she is with what does work.
Is it really that different in other professions? Does the doctor always bring good news? Are all of the teacher's students bright chaps? Does the firefighter save each and every life? The lawyer win every case? The financial advisor always make a plus? Are a real estate agents' clients always happy with their sales price? Sure, there are lots of professions where there are rarely any negatives, say, a taxi driver, but is that a rewarding job?
I think this is really about your mindset. I often feel like a sculptor... I start off with something that doesn't look at all like the final product I have in mind, and over time I approximate the final result closer and closer. Error messages or not, to me that's just feedback, just like the sculptors' fingers find roughly hewn spots on the surface. Is the sculptor supposed to get mad at a little rough spot on his sculpture? Of course not, he just chips it away.
The one suggestion I have for programmers who are offended by error messages is to give TDD a try. With TDD, the test failures you get are to be expected: after all, you specifically engineered them to fail in the first place. So you don't have to feel bad about those, and you can revel in the positive feedback you get from a passing test. And if a test fails unexpectedly you can be happy that your safety net has actually done its job! I'm not being facetious: if you see error messages as negative feedback (again, I don't, but maybe you do) then TDD might just give you the positive feedback you've been craving.
Impatient clients with overblown expectations notwithstanding, but you get to pick those :-)
Having the mindset that the mere existence of bugs constitutes a personal or professional failure is probably very unhealthy. Is this something developers experience? I've never felt bad about a bug before. I just go and fix it. No pain, just gain.
Breaking things and inconveniencing others are a much bigger drag for me. Those are the problems I stay late at work to solve.
It's not that "that the mere existence of bugs constitutes a personal or professional failure".
Rather, in order to debug I have to go into negative mode. It's a mindset where I'm mentally combing over something, trying to illuminate everything that's wrong with it.
It's not even that important that it's your code. Focusing primarly on the good aspects of something is a healthier mental model - but not one that will get your code debugged.
There's some irony to be found here. More likely than not, someone just like the OP built the bug tracking app that encourages clients/customers/users to give negative feedback and report problems.
This is also highly apparent in social apps (e.g. Facebook, Twitter, Yelp, etc). We encourage negative feedback when we give people a platform to do so. For better or worse, a lot of what we create is simply enabling the insatiable devil inside of people.
It sucks, but most people are unhappy and they will always look for another avenue to vent their frustrations. We just turned it into an easy-to-use textbox that's available 24/7.
You cannot expect people to be positive when the thing you gave them (seemingly, from their perspective) encourages negativity.
All that aside, you can't let people get to you. The world is getting increasingly judgmental and you just have to roll with the punches.
Have you ever done fundraising for a startup? To raise 1m - 2m dollars, you will on average talk to between 20 - 40 different investors during the seed round. At least half of these discussions will end with a "no". This is not a good feeling, because this "no" represents someone who has the ability to enable your company, your co-founders, your vision, your dreams, and even your employees to have a future. Being told "no" is incredibly difficult to hear in the early stages of a building a company.
My point is that being an entrepreneur, regardless of your role, is not always easy. Controlling your own destiny means you get the good and the bad; you're never shielded from the stuff that's hard to swallow. While I feel for this particular situation, I don't think other roles in a startup have it any easier.
This is exactly why I love test-first development for most (but not all) projects. Instead of code, run, bug.. fix, bug, fix, etc, I get to say "I want to achieve X!" and then strive towards achieving X. Rinse and repeat. A gross simplification but a test-first approach has made me a lot happier.
This theme has been on the tip of my tounge for a long time; in fact, I tell coworkers that I see every item that is in the ticket system, be it a bug or a feature, as a "delta", a change in the system to make it have some characteristic it doesn't have now.
I'll just say that stress management is one of the issues you must face if you're going to be an effective (and happy) developer. It's important to get exercise and take breaks, but it's most important to understand your sources of stress and deal with them. Sometimes you can take action, by say, getting a motorized standing desk and tall monitor arm to avoid pain. There are other sources of stresses that you just have to accept.
Instead of submitting yet another bug report, you should totally submit a "bug" that is nothing but positive feedback.
A truly good product will have fans sending in messages and talking about the things they love -- make sure these comments make it to the developers too!
Yah, but you always get that one person who no matter how good the product is can find a way to rip it apart. It's really sad :(. However the person who wrote this is most likely a "bug fixer", I know a lot of programmers who's day is
* Make something
* Meet about making something
* Make something else
* Go home
It is a different mindset when you are writing code and thinking 'Did I cover all the cases?' instead of 'What can go wrong?' For me, thinking about all the cases is a positive and fun thinking process, not a negative one focused on what can go wrong.
It really seems to me that in general programmers have such an good life that they (we) have to find something to complain about. I'm not pointing any fingers, since I often have the same thoughts. There was actually a quite nice article on HN lately (I read it on Sunday, but my google-fu is failing me), something along the likes of "Why wouldn't you want to be a programmer?", which arrived to the same conclusion as I usually do after trying to compare it to many other professions in an unbiased way: overall programming is quite a sweet deal.
I have to admit though that I never held any other jobs, so I'm very interested in reading about the opinions of those that have.
The same plight is shared by any creative person. If programming makes you miserable, you're doing it wrong. The feeling of sublime satisfaction when something finally runs and does what you expect far outclasses any transient misery inflicted by the terse crowing of the compiler.
Any path worth walking is fraught with forks that lead you through brambles and strife before returning to the main road. The painter seeks the one perfect brush stroke that comes next; the carpenter seeks the perfect arrangement of nails and dead trees. If there weren't a thousand thousand ways to do it wrong, it wouldn't feel so wonderful when you finally got it right.
I can identify with some of what the author has saying, as I've struggled with a pessimistic attitude throughout most of my adolescent and adult life. However much of it was formed long before I learned to code. I've recently been working to be more optimistic as I think it can be learned.
However, I suspect pessimists tend to make good programmers rather than programming causing someone to become more pessimistic.
If you're interested in understanding some of the psychology between Optimism and Pessimism, I recommend reading Learned Optimism by Martin Selligman. http://amzn.com/1400078393
"However, I suspect pessimists tend to make good programmers..."
It might also be that pessimism could limit programmers' capabilities by making them afraid to take on ambitious problems. Being somewhere in the middle of the spectrum might make someone a better programmer than being either too optimistic or too pessimistic.
how do you create good and worthwhile things if you do not try and make them better? how will you make them better without finding the elements that can be improved and improving them? maybe this is part of the engineering mindset, the ability to approach the world with "how can I make this better" and not be depressed and overwhelmed.
I used to get super frustrated and depressed when people edited my writing/prose. each comment was some way in which I sucked. then I compared, side by side, my early drafts with finished works. now I'm not frustrated or depressed when people find problems with my writing! or my code.
Perhaps it's all about context in terms of how you view how salient the negative feedback is. I can only speak of my experiences but I always found that no matter how frustrated I get while coding, the moment that everything finally functions releases such a dopamine rush that I quickly forget about the frustration.
Perhaps two things (probably more) are necessary in order to overcome this negative feedback loop:
Learning how to let go of failures.
Focus on the euphoria of fixing a bug.
Remember that as humans we essentially are very complex machines and perspectives partly determines how we will react to a stimuli.
Same a doctor could say, I guess—they look for problems in order to help. Too bad they don't have unit tests.
Finding a bug is good, the worse the better, not finding one means software has bugs you don't know about. Distance yourself. You shouldn't allow one project's problems influence your state of mind, since it can hurt other ‘patients’.
For me, most of the frustration comes not from working as ‘just a’ developer, but from leading projects and interacting with customer. It's exciting to solve higher-level problems, but communication is easy as the ocean.
If you don't like your workflow, change it. It's really as simple as that. If you can't change it, switch to a job where you can. Trying to change how other people perceive you or your job will only make it worse. Just because so many are feeling that they are stuck in a continuously endless loop of negative feedback, doesn't mean its right or the only thing there is. You, and only you, have the power to change your own mindset (for the better or worse). There's nothing that does that for you.
I think this is one area where dashboards can help. Chart the metrics that are important to your organization, and prominently display them.
Chart the number of users on your site throughout the day. The number of times they do X or Y, that your app enabled them to do. Put a big counter on the wall for sales/new users/etc. Make a big deal when milestones are reached.
Bug trackers, user complaints, etc can definitely weigh us down. But hopefully there's some encouragement in the data that we're doing some things really right.
I think that people need to realize that a developer is someone that simply builds the solution to a problem no matter what that problem may be (ease of use, a new business etc.) If you use that train of thought it only makes to focus on all of the things that do not work to successfully achieve the goal of finding the thing that does. So regardless of how good their code is the developer has to have the mindset of first fixing all the bad to deliver a working solution.
It's this way in every job. Every chef should be thinking, "does what I made taste as good as it can?" Every car repairperson should be thinking "am I doing the best job of replacing this brake caliper? Not banging it around, not kinking the brake hose, not getting greasy fingerprints on the rotor?
In every job you should be thinking about the quality aspects.
It's just that in programming, the problems can numerous, subtle, and hard to find.
On tough days at work, I am often reminded of Vladimir Vukićević's blog post about the "best visual representation that I’ve seen of what a programmer’s job is often like":
Doctors see sick people more than healthy people. Divorce lawyers get more business than the lawyers for happily-married couples (I guess they can help them with a will.)
We programmers live on the borderline between respected professional and prole grunt. Is it Doctor/Lawyer/Software Engineer; or Mechanic/Technician/Software Engineer?
Indeed. Or go work on software for manned space vehicles, or medical devices, or huge financial institutions, or anywhere where the consequence of bugs is "people die" or "national security is compromised" or "society collapses" or the like.
I wonder if you couldn't formulate a rule to the effect of the more serious the task you are working on, the less you can afford to be optimistic. When Serious Things are on the line, you have to be a pessimist, because you have to find and root out all the possible weird failure cases before they bite you. When all that's on the line is a comment on someone's photo of their lunch, optimism is a more sustainable philosophy.
Something that struck me from your comment is that yes, there are more serious repercussions than others. The problem here is that the pressure and feedback from those repercussions is relative, and knowing this makes it especially difficult to accept tons of negativity. If a bug caused someone to die, and this was preventable (i.e. obviously your fault) then yes, you should feel horrible. Most of our jobs though, involve loss of money, not loss of life. The pressure to fulfill these tasks is therefore completely constructed. Success or positive feedback is simply that the people paying you continue to make money, the status quo continues.
Being optimistic or pessimistic isn't quite relevant when people's lives are on the line, I think it's more about being _realistic_. Everything can fail, and everyone makes mistakes. This is reality. When people can die, there is much more impetus to pay (time and money) for everything to be triple-checked and triple-redundant.
But in pretty typical software development, that money and time isn't there. And the feeling of knowing you could have done better, if only given a chance, is horrible and eats away at your resolve. Then you wonder, "well perhaps I'm not fighting strongly enough," or "People are coding for space shuttles, and I can't even get this page to load!"
I believe it's a human right that your individual problems are no greater than another's, because it's relative. If you feel about it strongly enough, then it's valid. Saying it's not because people's lives aren't at risk is invalidating the human right of pursuit of happiness.
the point isn't the criticism coming back. the point is the critical thinking the programmer is doing. the problem is focussing on finding flaws and holes.
in social conversations and in life, it is a virtue to let things pass, to support the joy that comes from simple optimism, from believing in hopes and dreams without practical certainty or probability. it is a virtue to talk about things without knowing the context, without digging into the challenges, the holes, the flawed rationales, the white lies that help us feel better about ourselves, each other, and our journeys through life.
too much of anything is a bad thing. i just assumed everyone had this problem of focusing on the problems and undervaluing progress and success.
It sounds like a plateau, where he's not getting noticeably better from the mistakes he's making (so that he's not making them as much with each chunk of code he writes). Maybe this happens when you're close to your full potential?
Programming always gets more difficult. I'm a much better developer than I was 10 years ago and I don't make the same design or development mistakes. But instead of writing perfect code, I'm working on larger and more difficult problems. In fact I'm now responsible for so many more platforms, systems, and programs that I probably spend more time dealing with problems than ever before.
I guess my take on it is different. The things that I've found to be the source of bugs/problems for me are areas that can scale to larger problems. Things like component communication, algorithm edge cases, typos, poor memory management, etc. For me, the error rate slowly goes down, because I've learned to compensate for my weaknesses. Maybe your (and his) weaknesses are not as portable to other and larger problems/systems?
I'm sure my error rate is a fraction what it used to be but I'm producing far more code and working on far larger problems. You better hope that areas of improvement on are the ones that scale to larger problems.
The original article was about error rate, that's what I was talking about:
1. write some code
2. run the code
3. get an error message
4. find the error and back to step 1
Hour by hour, day after day, I do this. Always searching
for what's wrong with what I'm creating, rarely thinking
about what's good about it. It's a negative reinforcement
feedback loop.
If the error rate was lower, steps 3 and 4 would happen less frequently.
My original point was that #1 doesn't stay static -- if it did, then I'd be writing perfect code right now. Instead the code you write gets harder.
Even then, I don't think the author intended you to take that so literally. That's an easy way to describe the problem to someone who isn't a programmer. The negative feedback loop is much longer and more complicated than that.
I think part of progress is a continual taking on of new and harder challenges - new technologies, advanced features etc - so your error rate should be fairly constant
Indeed this is very dramatic. Positive feedback boosts egos, negative feedback gets the work done. If no one ever received negative feedback, we would spend our lives believing we're perfect while doing everything wrong.
Once I heard from an architect(in the original, designer of buildings sense of the word), that he wished he would get as instantaneous feedback of his work, as a developer can from a compiler.
this seems to be largely a matter of personal mindset. i'm a programmer. i've worked in a number of companies, from deeply dysfunctional to wonderful. but invariably, the only thing i ever disliked about my jobs was dealing with company bullshit and unpleasant people. i've never felt any negativity attached to my actual work - i always feel like i'm building something and making forward progress, whether that something is genuinely new code or simply bugfixes.
i disagree with the last part being that failing is frustrating... now it could just be me, but that's what i love about programming which is finding and solving puzzles that I've made subconsciously for myself.
it makes you wonder if the real success of companies like google really is in the uplifted, positive, work environment to help pull you out of that negative feedback loop.
lol, nobody gets paid to see the positive things. Everyone else at the company is also being paid to be critical and fix problems (lawyers, finance, HR, CEO, etc.).
This is extremely true. I love the phase where you are just building putting pieces together, solving interesting problems. Then QA comes in and tears your shit apart, gives extremely unhelpful advice and generally just kick over your sandcastle.
functional programmers get to express their ideas as code
imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas
just look at the research[1] coming out of the <del>Clojure</del> functional programming community - especially Datomic. once you learn how to get your defect rate under control, you have time to explore crazy awesome new ideas
functional programmers get to express their ideas as code
imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas
Stop drinking the cool-aid. Functional programming solves a lot of typing errors (if the given language has stronger typing than an imperative language) and makes composition easier in some cases (if the language is lazy).
But: an algorithmic error is still an algorithmic error, an incorrectly designed data structure is still an incorrectly designed data structure. No matter what language you use.
In addition to that, you get back a different set of problems: e.g. you have to reason about when something gets evaluated in a lazy regime in order for your program's heap not to blow up, and the translation to machine code is often not nearly as simple as an imperative language, which makes it harder to optimize functional programs.
You don't have to convince me of OOP's faults; Clojure is my favorite language. But I write code for a living, mostly in OOP because that's where the jobs are, and I do not write very many bugs caused by OOP's poor design. I write bugs when the business is ill-defined, or when I misunderstand how a library's APIs are supposed to work, or when I'm careless and don't consider "what do I do if this function returns false"; all stuff that will come up in FP as likely as it will in OOP.
Languages like Haskell show this tendency too, e.g. Oleg's work[1] (which includes research with lisps) although he also does awesome stuff with imperative languages too.
I'm surprised any of us can hold up under the withering torrent of negativity that is any serious programming job.
I actually don't mean this as a complaint, either. I've adjusted. I've been doing this for 15 years. But I've been sort of stepping back lately and looking at my job from other points of view, especially as I deal with coworkers who aren't so adjusted/adapted, and not only do I now understand where they are coming from, I find myself wondering how adaptation is even possible. It's absurd how negative the interactions are. Keep track someday of your professional interactions and look at how many of them are negative; bug reports, missed deadlines, "we can't do that", etc. Or perhaps, don't, if you've never thought about this before. I sure hope you have an otherwise positive workplace.