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.
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.
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.
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, 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.
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.
that is such a good feel
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.
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.
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.
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".
Some industries are absolutely comparable, but a much smaller number than I think you're implying.
Do you know when your sysadmins are doing the job right? When you don't notice.
The only possible way for a sysadmin to get noticed is to screw up.
"The lifecycle blah-blah-blah for the infrastructure team," he said "Is simple. They rack the server and that's it. I mean, what else is there to do?"
Which was ha-ha funny at first. Then I realized he was _serious_. And most of his minions were nodding their heads in agreement.
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 :)
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.
Same facts, wildly different interpretations.
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'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.
But for me, it is a matter of not caring about the bugs but enjoying fixing them.
13 years in the industry here.
Your ability to relate to, and communicate with, people in the real world (in depth) will degrade over time.
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.
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.
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.
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
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!"
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).
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.
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.
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.
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.
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.
Optimists see bug reports as a way to improve things. Optimists bet on early tech because they see a bright future ahead (rails 0.9? ios 2.0?).
Being pessimistic will only feed your ulcer...
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 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.
Life is pretty good.
The lamenting in this article is from somebody with very little perspective on what most people have to do just to survive.
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.
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.
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.
The challenge lies in getting motivated to go from the reward back to the work. :-)
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 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.
"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."
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.
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).
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?
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.
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.
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.
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.
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.
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.
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.
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.
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" :)
(Step 0 is possibly 'get a bug report')
1. Write a test
2. Watch the test fail
3. Write code
4. Watch the test pass (if fail, goto 3)
5. Make the code pretty
6. Watch the test pass
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?
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
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 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.
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".
Keep searching until you find the right role.
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.
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!
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.
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.
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 :-)
Breaking things and inconveniencing others are a much bigger drag for me. Those are the problems I stay late at work to solve.
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.
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.
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 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.
People who fix things can have a positive outlook on life, mostly because they improve and make the negatives into positives.
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!
* Make something
* Meet about making something
* Make something else
* Go home
And they never see or hear about bugs :)
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.
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.
This is a feature, not a bug.
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
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.
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.
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.
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.
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.
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.
[links to a humorous video with NSFW audio commentary]
This blog post is really silly. Writing software is refining something over time. You take a lump of clay and gradually shape it into what you need.
If you get all broken up about a bug or whatever, you should probably try to get some perspective.
We programmers live on the borderline between respected professional and prole grunt. Is it Doctor/Lawyer/Software Engineer; or Mechanic/Technician/Software Engineer?
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.
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.
Competence relies upon willingness to admit mistakes.
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.
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
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
Make the compiler responsible for something.
This is nothing new.
Negative reinforcements have arrived! (Great article, BTW)
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 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
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.
(Ps. I love functional programming.)
The flaw is in us. Our ideas are malformed and flawed. Simply expressing ideas is not enough.