This blog post is intended to sabotage any chance that I’ll get a “normal” software-engineering job, because I don’t think I could ever go back to a “normal” job.
I’ve become used to extraordinary jobs, not “normal” jobs.
The following 10 things, which I hate about software development as practiced in much of the industry, I think will keep me from ever being successful or happy in a “normal” software-development job.
Along with them, I list the antiviruses that I hope will help me avoid these diseases, if I need to go back into software development, even temporarily.
-
Incompetent managers. Software development managers in general graduated from being software developers. Unfortunately, the skills you need as a developer are different than the skills you need as a manager. The best manager I ever had was not a particularly good or experienced software developer. Rather, she treated management as a profession, read books on how to be an effective manager, attended seminars, took classes, and as a result, she was good at her job. But most software-developers-turned-managers don’t treat management as a profession. Instead, some of them become telepaths, who expect you to know what they need without actually telling you; others become micromanagers, who expect to be able to do all the actual development themselves, using your eyes and hands and brain; still others become arguers, the worst of both worlds, who instead of letting you do your job, take great pride in pointing out everything they think you did wrong. So the next software job I take, I will be interviewing and trying managers carefully to make sure they know how to manage, regardless of whether they are good developers.
-
Snotty developers. I must confess to going through a snotty phase myself. It’s part of growing up. You have to live as a snot-nosed, young-whippersnapper, green-behind-the-ears code slinger before you can mature into a wizened Yoda figure. In fact, part of me still may be a snotty developer. I’m definitely snotty when it comes to my own work, because I don’t want anyone telling me how it should be done, as long as I achieve the intended results. But as someone who’s been doing this shtick for 20-something years, I’ve grown weary of junior colleagues telling me I don’t know what I’m talking about. And when something doesn’t work out as well as they thought it should, they persistently maintain that it had nothing to do with them, despite the fact that they had ignored every piece of advice I gave them. There’s only one sure-fire remedy I know of for this problem, and that is to insist on a higher rate of pay. People may balk at paying you through the nose, but when they have to—especially managers—they not only accept your advice, they seek it out, because for the money they’re paying you, they expect you to solve their problems.
-
Commoditization. That is, the devaluation of specialized knowledge. The most obvious manifestation of this disease is the company who outsources its development to a third-party contract shop in India or Mexico, and then wonders why the project is falling apart at the seams. A more insidious and pervasive symptom has employers and clients boil a job down to a long list of buzzwords, pattern-match résumés to those buzzwords, interview you to make sure you really do qualify for the buzzwords selected, and then look for the lowest price. And then they ask you to do everything under the sun, including those tasks that could be handled by a $20/hour contractor from Mexico. Instead, they ought to be looking for solutions to specific problems or for people to fill specific roles within the organization. For veteran jobs, that’s no longer about price, however, because if you’re specific enough, you’ll likely find only one or two qualified candidates, if you search for them, and whatever they want to charge you, you’ll pay. Again, the only sure-fire antivirus I know of is to demand a higher rate of pay, because for the money they’re paying you, they won’t treat you like a commodity.
-
Slipshod engineering practices. I am one of those programmers who actually believe software development is engineering. Many developers don’t believe in software engineering, or at most give it only lip-service. But software engineering is like gravity: you may not believe in it, but the result is the same when you step off that cliff. Developers who don’t believe in engineering experience bugs, hold-ups, overwork, and stress. To account for it, they blame the code, the programmers who worked on the software in the past, their development environment, the operating system… But they never do anything to fix it, because “we just don’t have the time.” Note, however, just because developers complain about not having enough time to fix the system doesn’t mean they’re using slipshod engineering practices. In fact, those developers who don’t complain are probably the worst offenders. Often, good developers complain about the code, but it’s really not that bad, because they’ve already fixed the worst parts of it, and the problems that are left just stick in their craws. These are the developers I’d love to work with. The quickest way I know of to assess the situation is to look at the code: Is it well-architected? Well-designed? Are there unit tests? If so, the team is probably using good engineering practices.
-
Neglect of quality. By “quality,” I don’t mean over-designed, fluffy, overly glitzy software. What I mean is, simply, software that works, that satisfies the customer’s needs, makes the customer swoon, has no bugs, does not constantly poke you in the eye—”See that?!” Ow! “See that?!” Hey! Cut that out! Quality is important, because it gives a team of engineers a sense of accomplishment, of pride, a healthy morale. And engineers who value quality will be professional, always improving their craft, always building better and better software. Again, a quick glance at the codebase should give some idea as to how highly the team values quality, because a quality team will use sound engineering practices. But you could also look at the finished product, and especially customer comments on the product and its support.
-
Black-and-white thinking. Frankly, I hate having my good ideas shot down with dismissive comments like: “Unit tests don’t catch every bug.” Yeah, but they catch more bugs sooner and cheaper than any other method of testing. Polarized, black-and-white thinking is actually a sign of depression, of hopelessness, of having given up. “My life isn’t perfect; therefore, I have no reason to live.” Sounds silly when put that way. But how many software teams are in a similar, self-imposed depression? “That technique can’t solve all our problems; therefore, it’s not even worth trying.” Almost every team has a naysayer, but such sentiments can cause actual depression in the more innovative among us, who actually want to better the team and its engineering practices. The antivirus is simple, if not easy: Early in working with a team, try to find one or two simple process problems and propose simple, direct solutions. Then sit back and see what happens. If you get a lot of hemming and hawing and ignoring and naysaying, think about whether you should split.
-
Focus on establishment. Humans have a natural need for stability and for camaraderie. That is, they need to feel like the floor is firm beneath their feet and that there are others on their side. But in some companies, these tendencies can become dysfunctionally pervasive. If you continue to do only what you’ve always done, only what everyone else is doing, you’ll always be safe from blame. But humans also innately need to do what they haven’t done before, to stretch their minds, to create. Because this gives one a sense of purpose. Rather than playing it safe, we should always be trying new things, and keeping those that work. But the dysfunctional company focuses on establishment, rather than on results. The antivirus is similar to that for black-and-white thinking. Early in the experience, try something new, and then see what happens. Do it early, before you develop an emotional investment in the project. It might even be best if the thing you try fails completely, because then you can see how the team handles failure. Even if your experiment fails, they should not make you feel like a failure for having tried it. If they do, think about whether you want to stay there.
-
Ignorance of modern research. Quick! Name at least 2 of the 9 teamwork-killers Tom DeMarco and Timothy Lister identified in their landmark work? It should be pretty easy, because they identified 7 of those 9 back in 1987. That’s what I mean by “modern.” Here’s another one: What 3 characteristics must a software team exhibit in order to have any reasonable chance of success, according to Alistair Cockburn in his research? Peopleware (2nd ed. 1999) and Crystal Clear’ (2005), for starters. This is what I mean by “modern.” Heck, we might as well even include The Mythical Man-Month in the list, because too many software engineers have never read it, either. At my next interview, while the development staff are quizzing me on my knowledge of Perl programming, PHP, and JavaScript, I’ll be sure to quiz them on their knowledge of Demarco and Lister, Cockburn, Schwaber and Beedle, Kent Beck, Michael Feathers—and of course, Frederick Brooks.
-
The blame game. Being caught in the blame game can cause stress, exhaustion, demotivation, and depression. It can also be the source of other maladies, such as black-and-white thinking, as engineers attempt to cope. Unfortunately, staffers don’t usually like to talk about the blame game, but a pointed interview question might reveal something. Something like: “Tell me about the last, big mistake someone made that cost the company money.” What was the fallout? Did anyone get yelled at? Fired? In a perfectly healthy organization, no matter how bad the error was, no one will have gotten yelled at; rather, it will just be accepted that everyone makes mistakes, because we’re all human, and the whole team will have looked at the process (rather than any particular person) to see how to avoid an analogous oops in the future.
-
Unrealistic expectations. I’m talking about the top-down variety here. Yes, engineers can—and frequently do—have unrealistic expectations of themselves. But that’s easily enough fixed. (Or at least I know how to fix it, with a bit of measurement, in my own estimates.) But I’m talking here about something different: Management wants such-and-such at such-and-such a date, and they won’t accept your promise that it simply can’t be done. When faced with such a situation, there are only 4 things you can do: Deliver less functionality. Take longer to deliver it. Reduce the quality (leading to delays because of unexpected bugs, and see #5 above—better yet, forget about sacrificing quality). Or spend more money (but adding people to a late project only makes it later—that’s Frederick Brooks, see #8 above). Management, under pressure, may not want to make real-world trade-offs, leading to overwork, demotivation, and depression for the engineers. Like the blame game, I don’t know any sure-fire way to discover this problem early on, because no one wants to admit to a new recruit that he’s walking into the lion’s den. But you might try asking about the team’s last overconstrained project or iteration, with a knowing, Columbo-esque gaze, and see if it prompts any reaction at all.
Now, if you happen across this blog post because you’re considering me for a job position, and if you think that I’m being abusive and unreasonable here, well, that might be a hint that I don’t want to work at your company.
Just a thought.
-TimK
By David Kramer July 22, 2009 - 1:35 am
/me reads last paragraph
“Glad to see you got over your snotty phase!”
But I get your point. It’s like “If you think Dilbert is funny because it’s true, then I don’t want to work for you. If you think Dilbert is depressing because it’s true, then we understand each other”.
By Choy July 22, 2009 - 4:04 am
“Always being the victim” is a habit that is hard to shake off. You can take almost all of these “hates” and turn them around to highlight your skill and expertise which is somewhat evident between the lines of this rant.
By Artem Marchenko July 22, 2009 - 4:19 am
What you describe is quite accurate for most big corporations. However, it isn’t always true for small companies and is never true for 2-5 people start-ups 😉
So it these are the only reasons you hate SW dev and you like SW dev itself, why not think about a startup? You could, for example, base on your new experience and e.g. help with some IT/web problem the new book writers have (I bet you’ve got some).
Though startup probably breaks the whole idea of getting SW dev-related job just for money 🙂
P.S.
I am all the time reading your blog in RSS reader and today was the first time in weeks (or months?) I visited it on the web to post this comment. At first I thought the link was wrong – the design changed really much 🙂
The current design is quite nice and I think is a bit easier to read
By J. Timothy King July 22, 2009 - 12:53 pm
David: Yeah, I definitely have not gotten over being snotty. 🙂
Choy: I guess I’m just weary of being the odd man out. I’ve worked with a number of developers that I’ve admired and respected (and I trust for whom the converse was also true). But I’m tired. I want to live. I’m just tired.
Artem: Actually, the last bad experience I had (which I haven’t posted about yet—still too close to it) was with a 4-person startup. I came on as a consultant, along with a couple others, to help them out with a short-term project. They ignored most (if not all) of what I (and the other consultants) told them; the whole experiment was a disaster; and the experience plunged me into a deep depression, from which I still haven’t completely recovered. (Which might be evident in the above post.)
-TimK
By Artem Marchenko July 22, 2009 - 4:27 pm
Oh, I am sorry for your bad experience, Tim. I meant becoming one of those guys who start a company and therefore establish the rules.
By Rick July 23, 2009 - 4:35 pm
Oh man, this sounds so much like me it’s scary. Choy is right about “always the victim” mentality, but the only alternative seems to be to stop caring.
And I’ve worked for startups and small shops a lot, but I’ve encountered exactly the same issues there as TimK describes. I’m working for one now, and I’m seriously considering moving on before I get as depressed as TimK (been there too, and not going back).
By Jack April 19, 2016 - 2:12 pm
Sounds like Choy bit “The Oz Effect” hook, line sinker. The concept of a victim mentality is highly over used, and does not apply here.
By J. Timothy King July 23, 2009 - 5:39 pm
Artem: Oh. I get it now. Yeah, a startup is not a bad idea, if you have the capital or cash-flow to get you through the initial phase. I might do something like that, with a friend and colleague of mine—we’ve been informally batting some ideas around.
BTW, thanks for the nice comments on the blog design. It’s actually a stock WordPress theme, called DeepBlue. After some research, I think it’s pretty close to what I want, but I plan to customize it.
Rick: One of the reasons I wrote this, even though it might seem negative, was to give me hope that I might actually be able to avoid some of the things I’ve hated most about working in SD shops.
Dedicating all my time to writing and being an author has helped me feel better, to lift my depression, because it’s something I really enjoy. But as I don’t yet have a large fan-base, marketing is quite difficult. And for cash-flow reasons, I fear (in the most literal sense of the word) that I may need to pick up more SD work to make ends meet. Just the thought sends me back into depression: not healthy. So I’m trying to come to terms with the idea, find some way to turn it into a positive experience.
Thanks for all your support, you guys. I appreciate it.
-TimK
By LimeSpace – IT » Die beliebten Links der Woche July 25, 2009 - 4:51 am
[…] Highlight diese Woche. Ein sehr gelungener Beitrag (leider in Englisch) mit dem Titel “10 Things I Hate About Software Development“. Wir freuen uns über Bookmarks ! Diese Icons verlinken auf Bookmark Dienste bei denen […]
By John July 25, 2009 - 4:48 pm
I tried to do an anacrostic but gave up. These ten, I relate to. Difference is: approaching retirement I just shine shoes now for a living….
By Nine Teamwork Killers « Fearless Bit July 25, 2009 - 6:26 pm
[…] Teamwork Killers While reading 10 Things I Hate About Software Development, I came across a list of nine things that kill teamwork that TomDeMarco and Tim Lister in their […]
By J. Timothy King July 26, 2009 - 12:57 am
John: Re shining shoes for a living. Yeah, that’s another blog post. Bizarre and backwards.
By Jerry July 31, 2009 - 2:44 pm
Tim,
I felt much the same as you did and when laid off after my last software gig, I decided to get into education. Went back to school, got my BA, finished my MEd in a year and have been teaching for 4 years now.
Oddly enough, all 10 are true there as well, especially number 9, the blame game. I wonder if it is the personality or the endemic problems in ‘systems’ in general that cause these issues. So many people are able to completely ignore these issues, others rail against them, most seem oblivious…
Good luck to you, and I hope you find and answer that works for you!
Jerry
By octopusgrabbus September 7, 2009 - 3:30 pm
Were we separated at birth? 🙂 Enjoyed the post.
By J. Timothy King September 15, 2009 - 5:26 pm
Jerry, I know that the same symptoms occur elsewhere as well. That’s probably why I’d also not make it in a “normal” job in any other industry, either. Ya know, at some level, these diseases are endemic to human nature. That would probably make a neat topic: exploring that question.
Thanks for the complement, octopusgrabbus.
-TimK
By Roger September 24, 2009 - 12:47 pm
Tim, your post really struck me today – I’m sorry I didn’t see it earlier. But in all reality I’ve been in your shoes many times – some would call me a dinosaur because of some of my hardened but flexible ways. When I was just a Jr. Programmer in the late 70’s and early 80’s I was very cocky and one of my favorite reads was the “real programmers” (use Fortran) – during that time F-66 was my second choice of languages, and assembler was of course the primary. Throughout the years though, I’ve had to “change” my dinosaur ways and include the dreaded “C” compliers and other bloat ware compilers – As a side note I still have little if any use for many of the CASE type tools (Bloat ware). I still enjoy pounding out asm code in my spare time but for work purposes, I have to appear at least to tolerate the many Visual CASE tools. This being said, and now being one of the more SR. developers I have fun with some of the “right out of school” types that think they know it all with the bloat ware they love to write being torn apart to make it work faster and better – nothing like pulling out several thousand lines of code that are never used!
Hang in there, those of us that have been around for awhile are appreciated, but as you mentioned, we really have to be “picky” as to who we transfer to or work for. Next time you have a wet behind the ear green horn ask them to blow a prom (not more than 2K min you) that can boot an LSI and input 30- 50 inputs (analog of course) that can be streamed to a DC-600 formatted and rudimentary stats that will work with RT-11 on an old PDP! – Sorry for the reminiscing – but I do miss those days!
By J. Timothy King September 24, 2009 - 4:56 pm
Thanks for the comment, Roger. That last paragraph gave me a healthy chuckle. The PDP-series is a little before my time, but indeed, I could plug my own ancient technologies in there. I’ve burnt plenty of PROMs (though by my day, we were generally using EPROMs). And I was one of the first engineers at my company to work with FlashROM when it first started becoming feasible for production use.
Although for web development, maybe a timely reference to gopher might be apropos. 🙂
-TimK
By Yofie Setiawan March 15, 2010 - 12:47 am
agree with number 1, incompetent manager could make worse everything, not only software development, but also another kind of development such as web development…
By Armen Grigoryan March 15, 2010 - 3:38 am
For me software engineer, manager and entrepreneur are all talents (they can be revealed or trained, but you need to have one). And the most important ingredient is that you have to LOVE what you are doing. Next one is result orientation which will help to see the situation from outside and help to avoid most of the problems 🙂 The work should be a complete joy to feel good about yourself and achieve greatest results!
By justen March 15, 2010 - 6:16 am
great article and i agree with all the points here..
By J. Timothy King March 15, 2010 - 1:59 pm
Thanks for the comments.
I agree, you have to love what you’re doing. But I’ve seen too many engineers become managers and then still act like they’re just engineers. Managing a team requires a different set of skills, and you have to study and work to develop management skills if you want to be a good manager. I agree about “result orientation,” in that you have to take joy in what your team accomplishes, and not in what you yourself accomplish. It’s a completely different mindset than when you’re doing the work all yourself.
-TimK
By Kuroi Kenshi March 15, 2010 - 8:22 pm
Your points are dead on. I’ve experienced most of the things you mentioned at my old job, which drove me to leave. Now, I’m freelancing and couldn’t be happier.
By Weekly Round Up | Barry McGee March 19, 2010 - 12:23 pm
[…] In a similar vein to the above, I could also identity with 10 Things I hate About Software Development […]
By Rachel April 5, 2010 - 9:37 am
I agreed with some of what you said above. One thing I don’t agree with, though, is the idea that competent engineers often don’t make good managers. Of course, management is a skill in and of itself, and a percentage of engineers will not have that skill, regardless of how good a technical person they may be. However, in my experience, I’d say it’s more often been the case that good technical managers that have once been in the shoes of the people they’re managing will happen to have the skills needed to manage technical people, than people who are merely good managers in theory will have the technical aptitude needed to absorb and react to the feedback received from the technical teams they are managing. Some of my least fulfilling jobs have been working under know-nothing Prince II and ITIL -certified management types, who, though they may have been knowledgeable about abstract management theory, unfortunately had precisely zero flying hours in actually creating software and therefore knew squat about how to plan and build reliable systems. Worse, I’ve found such people are all too often too dumb to make up for their lack of acumen by actually listening to their direct reports, unlike managers with a technical background who will at least be able to discuss *why* they disagree with the people they are managing if they decide not to follow their advice. The public sector in the UK seems to be particularly afflicted by such ‘all theory, no skills’ people, which is what leads to 70%+ of the public sector IT initiatives in this country failing abysmally.
By SaaS February 8, 2011 - 1:07 pm
Why don’t you tell us how you really feely Tim!!! Great post, I learned alot. I have also ran into some of these management problems. Good managers are hard to find but oh so easy to work with and so are collegues. I liked #2, this is the worst part of any job, the guy that knows everything and knows he does.
By J. Timothy King February 10, 2011 - 12:52 pm
Why don’t I tell you how I really feel? Because I didn’t want to appear too extreme. 🙂 -TimK
By un-excogitate.org » Blog Archiv » The Path to Software Security Is Littered With Obstacles (and they’re not technical) February 11, 2011 - 10:02 pm
[…] of software development, in fact, on the very same day J. Timothy King was also writing about the 10 things he hates about software development, including: “2. Snotty developers. I must confess to going through a snotty phase myself. […]
By Prashanth July 5, 2011 - 5:42 am
I am not sure, if this blog post accepts anymore comments.
Yeh!… I totally totally agree with point #2.
The important character for any manager is to trust their developers. Often in corporate world, I am seeing this imbalance of managers not trusting their developers and try imposing their own ideas / estimates thereby screwing up developers life. @ one point of time I almost thought if quitting the job and do a decent forming. But then, I have a dependent family.. Sometimes I question myself whether it is too late for software professionals to learn good management.
Are we running after time and money?. A good manager is one who understands what it takes to make the project success in an ethical way not through short-cuts and burnouts.
Software development is an engineering / an art and it needs time to shape up. Quality can never be achieved overnight come what may. Engineering needs precession and & discipline not “Count the Sheep” attitude.
Someone’s incapability is not our weakness.
I have just completed(June 2011) 12 years in IT Industry.
By Darryl October 9, 2011 - 10:56 am
Great list! In addition, my problem with software development is that it is a dead end career. There is no glamour, no recognition; you end up living a life consumed by details. Most people starting a software engineering career now will wake up 20 years later with no job, no interpersonal skills, and a major career and personal crisis in their 40’s. Not a good deal. My advice to young people: Don’t put all of your hopes and dreams on a stupid box sitting on your desk. My advice to software developers: Go back to school and find another career.
Seriously! The software developers of today are like the machinists of the past. You don’t see many machinist jobs today, do you? How many programmers in your 40’s do you know? Outsourcing, open software, and automated tools will kill this career path. Wise up and get out before it is too late.
Programming will kill your soul.
By David Kramer October 9, 2011 - 11:42 am
@Darryl: I hear you, but that’s not the path for everyone. I have both a management degree and a computer degree, so I look at not just the geeky side of things, but the business side of things.
What I see are a lot of people who get into software to make big money that don’t have a great love for it. For those people you’re right in that most of them will never make it big. They often learn one skill (one language and/or one application type) and try to find work within that specialty. I once had a developer work for me that did not even own a home computer.
Then there’s people like me. I fell in love with computers way back in Junior High School. Two decades later, I am still learning and expanding my skill set and being hounded by recruiters. And spending a few more hours on my computer every night after work. Just last night I was up til 11:30pm learning more about Apache Maven so I can make myself more valuable at work. My company is full of people like that, because they’re a better long-term investment.
I’m not trying to brag here, I’m just saying that there are a lot of us out here that love software development and keep moving forward. And I’m not just talking about antisocial shutins. I have a family, and lots of friends, and go to parties, etc.
By Darryl October 10, 2011 - 7:02 pm
@David Kramer. You are responding to an article titled “Why I Hate Software Development” attributing career frustration to insufficient professional preparation and lack of motivation. Then you proceed to contrast their disenchantment to your own delight and success, which you attribute to true love and dedication for your profession.
Do I dare suggest that is not the best example of social sophistication? I’m not saying you are an “antisocial shutting” by any means, but you may want to consider the possibility that your comment may appeal more to your technical than your business side.
By David Kramer October 10, 2011 - 7:47 pm
Daryl, I don’t think it’s bad form to comment on an article by offering a dissenting opinion. What would be the point of discussions if everyone agreed? Yes, my career worked out differently than Tim’s, and a lot of other people.
I would say that it was being aware of the business side is what made me realize that I had to keep changing and adapting my technical side, and just as important, find ways of doing it on the company’s dime.
Another thing I think I should make clear, is that my intention was not to put down other Software Developers (past and present), but to give hope, and say that it doesn’t *have* to be like that. Like any profession, you have to be mindful of the culture and practices of the companies you join, and open to the opportunities that come your way.
By Darryl October 10, 2011 - 10:13 pm
David,
Nothing encourages creative thinking like diversity of opinions.
Usually, doing what you love leads to success. Constantly improving your skills certainly helps a great deal. So why do I still think Software Development is not a good career choice? It is because most corporate environments make it very difficult to upgrade your skills and/or put them to use. Most programming shops are in constant crisis mode and developers are running around like chickens with their heads cut off trying to put out fires and meeting unrealistic deadlines. A job like that is like a baby so ugly that even his own mother would have a hard time loving.
Typically, developers get pigeonholed into a job and that is what they do for many years to come. Even if they do learn new things, they can’t claim that experience on their resumes. They better not; learning is no substitute for professional experience! Now, eventually shops do switch technologies, but when that happens 80% of the team goes out the door.
On top of that, the current trend is taking the power away from IT and putting it right into the hands of business users. The cloud, along with innovation coming from Adobe, Microsoft, Google, and Force.com among others is a clear indication of that.
Finally, I have to apologize for misinterpreting your post; programmers certainly need hope. At the end, each person is in a different situation. Software development may not be my cup of tea, but that doesn’t mean it is not for everyone.
Take care,
Darryl
By David Kramer October 10, 2011 - 11:16 pm
You’re probably right, most software shops (or at least a very significant portion of them) are like that. And when jobs get scare, developers pay less attention to the company culture when choosing their next employer, even though it may be a bad career choice in the longer term, because they need the money now or just don’t see things getting better soon.
I’ve been focusing heavily on Agile practices, and looking for companies doing *real* Agile (usually Scrum, but some XP), and that filters out a lot of those kinds of companies. Agile has a balance of power that makes it harder for employers to become sweatshops, promotes meritocracy, and puts out many of the fires that occur in non-Agile shops. Not that crises don’t happen, but the overly-inflated crisis-of-the-week is harder to perpetuate when you can fold new requests into the prioritization process every few weeks.
By J. Timothy King October 12, 2011 - 11:35 am
Darryl, David: I posted a follow-up to your comments here: http://blog.jtimothyking.com/2011/10/12/software-development-a-love-hate-relationship.
By Dinesh February 22, 2012 - 1:43 am
Thanks Tim for putting all the things we experience out there in words and with such clarity/simplicity – does make one wonder if utopian development company could ever be found. Nothing is perfect means there is job to be done 🙂
By UK Software Development Company Blog February 28, 2012 - 1:33 am
Aw, this was a really nice post. In idea I would like to put in writing like this additionally – taking time and actual effort to make a very good article… but what can I say… I procrastinate a lot and by no means seem to get something done.
By Joshua Warren May 18, 2012 - 4:50 pm
Most developers(sincere ones) have gone through similar experience faced one or more of the above aspects of being a part of a team. But whatever profession you may have, you will face similar circumstances in different mask. The best way is to concentrate on your job not only for the sake of your team but also be a little bit selfish. As you are likely to learn something in the process. But if you want to avoid all the points, then the best way is to be a solo player or choose a like minded team.
By emulation October 27, 2012 - 2:00 am
Indian companies have the talented and dedicated professional team because clients that are Outsourcing their software services with India may get exactly what they have expected. There are many reasons behind India’s popularity in the global IT market but its efficient human power is the key factor that is making software services more reliable and robust.
By Kristy@Racks and UPS March 7, 2013 - 2:27 am
I think meeting those kind of people in the real world is a major challenge than the job itself because those people are the one who will be your friends or better yet your worst enemies.
By paul April 10, 2014 - 8:46 pm
I so agree with the first point; bad managers are everywhere but more so in the development business. Being a Manager is its own expertise and not a natural progression for a software developer (perhaps a software co-ordinator)
A Manager has to hone a larger skill set than just being a great software developer. Understanding how to motivate people and understanding people takes time and experience and I don’t see a lot of that with a ‘promoted’ title from developer.
By Eric May 22, 2014 - 4:30 am
Tim, Thank you for writing this -It really helps.
By Rajesh August 14, 2014 - 10:53 pm
Liked what you say. I think the problem is developers by nature are full of it (hubris). Every developer thinks he has created a Mona Lisa. In what other profession folks give away years of sweat and blood for free(open source) ? Well may be Jihadis.
Scrum is another thing !! Developers created it. ’cause they hate other developers (how dare they best my Mona Lisa).
Marketeers don’t have to go through that !! Accountants don’t have to endure that !!
I work round the clock so I can make ends meet at work so I can satisfy the blood thirsty scrum master who might insult me in the forum if I’m late at something, or I can’t give her dates yet !!
I’m done, I am quieting development and becoming a manager.
By Gerald June 23, 2016 - 3:39 pm
Just wanted to give a hearty HERE HERE to this article. All true! And wanted to update the comments on the timeless classic manifesto .. this thread shouldn’t die 🙂
By Kriscent Techno Hub November 10, 2022 - 12:33 am
Very informative knowledge, content is super, thanks. Great Job.