11 ms·

I’m a Bad Developer, That’s the Only Reasonable Explanation

177 points by passenger 10y ago

_Marak_ 10y ago
I'd suggest trying to focus more on using tools related to building reports on code coverage and code complexity during your day to day development. If you lean more towards a test driven approach backed with trackable metrics for code quality, I think you might have more confidence in your day to day development and ultimately be more productive.
- amriksohata 10y ago
  You do realise even the founder of TDD doesn't back it anymore and code coverage is a very poor metric, your words sound like a senior developer from 2010. If he's a bad developer the best he can do is read up on SOLID principles and read a book like Clean Code with good examples of how to write code.
  - amriksohata 10y ago
    That said, from the article it just sounds like he's worked for shitty companies that don't understand the value of not writing code twice
  - jghn 10y ago
    "You do realise even the founder of TDD doesn't back it anymore" I ask this out of genuine curiosity but do you have a cite for this? Being fairly anti-TDD myself it'd be good to keep this factoid in my pocket.
  - matthewmacleod 10y ago
    TDD is still a fine tool and the field hasn't moved on so much in 6 years that it's a stupid suggestion. It's a perfectly viable tool for helping to maintain output quality - like all other tools it might not work for everybody, or it might have to be applied carefully. But I wouldn't advise anyone to cargo cult the apostasy of a single proponent.
  - emmelaich 10y ago
    If you're referring to https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847/ https://www.facebook.com/notes/kent-beck/rip-tdd/75084019494... he was being sarcastic. But he also has said it can be over-done. Which is not surprising, because everything that can be done can be over-done.
auggierose 10y ago
I am not sure what this post is about. Just realise, when you are working for somebody else, of course they would like repeatable good performance from you. Some people are able to deliver this better than others. In my experience, thinking through a problem thoroughly and not giving a shit what others think is the most comfortable and most efficient way to work. Not even sure why you would consider working for somebody who stops you from going to the bathroom.
- zzzcpan 10y ago
  Also not sure what the author is trying to say. But sounds like a really bad management is trying to pressure him. He won't be able to work like that for long. Probably better to start looking for another job and without a time tracking.
exratione 10y ago
Everyone has been put in the position of coming to a dead halt on some aspect of the work that just won't yield. Or at least not for the combination of you, your knowledge, and your resources at that given time. This never goes away. Signs of maturity as a developer involve how you deal with the existence of this phenomenon. E.g. box your time, know when to seek alternatives, and know how to find solutions that exist already, and especially know when to pull in help - and how to find useful help in your network. The driving overall concern is avoiding points of grinding minimal efficiency for individuals, and in near all cases that can be avoided via some combination of simple strategies, even when you are the only person on your own personal project. Development is such a huge space that no two people will overlap completely in skills and experience on a team, and pulling in other people to alleviate your dead ends is a part of how you learn specifics needed to avoid that dead end in the future. But it is knowing to pull people in or seek another path that is the important part, not the specifics. Working to an absolute dead end is only useful in the sense that you then understand better the incentive to avoid doing it again if you can. An alternative view on the same problem space: https://www.exratione.com/2016/01/paid-a-great-deal-to-be-terrible-at-development-most-of-the-time/ https://www.exratione.com/2016/01/paid-a-great-deal-to-be-te...
- a3n 10y ago
  > box your time What exactly does that mean. I'm not saying this isn't a real thing (I really have no idea), but the only time I've heard the phrase used in person was by people who get ahead by posturing. When someone uses it sincerely, what do they mean? What does it look like, as opposed to not boxing your time? What specifically does it solve?
  - tbirrell 10y ago
    I've always understood it to mean that you put an arbitrary deadline on the issue. ie "If I have not solved this by 12:15, I'll get help/move on". I'm not sure why it's called "boxing time" and I could be totally off base, but it makes sense.
  - RandomOpinion 10y ago
    >When someone uses it sincerely, what do they mean? What does it look like, as opposed to not boxing your time? What specifically does it solve? A technical analogy would be depth-first search of a solution space, e.g. in a simple chess AI. If the search has a cut-off depth = deterministically bounded length of search time = time-boxed If the search does not a cut-off depth = unbounded (potentially infinite) length of search time = not time-boxed
jeremiep 10y ago
You could change jobs. An employer tracking your activities to the minute sounds like a cancerous work place to begin with. Bad employers are also a thing, and is much more frequent than most people realize. They usually drown you in tools and processes along the way and without much development experience its hard to tell whether they're bad or you are. You're going to hear about Agile, TDD, code metrics and whatnot. Its all superficial at best and those promoting them don't usually have quality products on their hands to begin with, or have codebases much larger than actually needed. At least from my experience its that way. Its best to find an employer who can help you grow instead of fitting you in a box.
- rplst8 10y ago
  I think you are lumping things together where they don't belong. Processes and tools have places. As I've posted previously on the topic, some industries have strict quality standards, and the tools and processes are there to find and prevent bugs from making into fielded systems. These process can an do work, but don't always apply to a basic website or CRUD webapp.
  - jeremiep 10y ago
    Oh definitely, I was referring to things like Jira, Scrumm and the likes rather than industry standards.
    - ConnorLeet 10y ago
      Tools to help with a process, not to define the process.
0xdeadbeefbabe 10y ago
I suppose if you help someone do something they could not do themselves then you are actually a good developer, something like writing minecraft. It seems like your criteria for being a good developer is more complex, maybe even hopelessly more complex. Why don't you try charging them 10 cents for each trip through your code? Lawyers do that, and feel like it's okay.
transfire 10y ago
Good software requires teams, and teams will always vary in the member's skill levels. Some programmers are better than others -- that's just a fact of life. But even if you are not one of the best coders, that doesn't mean you shouldn't be a coder or that you shouldn't be considered a valuable member of a team, so long as you provide a meaningful contribution. You may get paid less, but that's okay. You shouldn't beat yourself up over it. Do you enjoy the work? Do you at least get stuff done, even if it is not as much as your coworker in the same period of time? Then your okay. And that's okay. You just need to find the right niche. Not every coding job is with a startup or contract firm that needs to pump out the code a mile per minute.
- urathai 10y ago
  I agree! You should always remember that (about) half of the people perform under the average and there is no real way around that. Not everyone can reach the top and that is something I think you need to accept at times.
trjordan 10y ago
Estimations are a game we play. To understand how good you are, you need to figure out what's happening with the business and understand the impact you're having there. For a small company, this is probably the rate at which you ship features. Good developers ship enough that there's pressure to constantly explain the improvement to sales / marketing. For a larger company, this is probably a user metric. Are this things you're doing moving the needle on logins, time on site, repeat visits? You should understand what areas of the product are high value, and which are experimental. You should spend your time converting experimental features to high value features. Polish and edge cases. For a bigco, this is probably scaling metrics, like page load time and uptime. You should have clear targets you're working against and be able to prioritize against that target. Numbers are easy to show results against. Anybody can be fast against sprint points. You need to understand what the business goal is and play to your strengths against that goal.
probinso 10y ago
Pay has little to do with throughput. Pay is an arbitrary number that you and your handler select from the ether. This decision is often made well before there is any chance of measuring your productivity. If you think the number was poorly selected, just know it is. I found time tracking tools to be hugely beneficial. It changed my focus, and forced me more aware of what I was working on. I am, however, a slow developer sometimes. It is just who I am. I found that often employers look for 'smart' candidates, instead of SMEs. This is their fault. If they were interested in / could afford a subject matter expert (SME) then you wouldn't likely be working there. If you are an SME, then you will likely produce results/prototypes far faster than others. Smart people take time to learn, thats how they got there.
- tbirrell 10y ago
  SME = Subject Matter Expert (if google is to be believed).
  - nishs 10y ago
    Yes. Also defined in author's last paragraph.
    - Noumenon72 10y ago
      I saw it, but only because I had started skipping through his post knowing it wouldn't make sense unless he explained SME. Poor communication habit.
      - probinso 10y ago
        thanks for noticing! :)
  - probinso 10y ago
    google is to be believed
karmajunkie 10y ago
There are a lot of ways to dice up performance as a developer, and while some are clearly bad, like LOC counts, others are merely different from each other. Is it better to ship a feature faster? All things being equal, sure—but all things are rarely equal. All bugs aren't created equal, nor features, nor design requirements. Nor are the skills needed to handle any or all of those things distributed equally amongst developers. I was on a team once where my diagnostic skills put me near the top of the stack for being given hard-to-find bugs. What that meant was that sometimes I would ship one commit a week while tracking down several difficult issues. Does that make me a bad developer? A slow developer? Or are those even valuable distinctions in this context? Rather than trying to be better than everyone (anyone?) else, try to be better than you yourself were last week, or last month, or last year. That's the only consistent variable one has across all the kinds of tasks we are called to perform in this role.
- rplst8 10y ago
  >I was on a team once where my diagnostic skills put me near the top of the stack for being given hard-to-find bugs. What that meant was that sometimes I would ship one commit a week while tracking down several difficult issues. This. A good management team will recognize these skills in people and assign them appropriate work. All people are not the same, that's why we have developers and doctors and fireman. All developers are not the same, that's why we have backend, frontend, Java, C++, etc. All backend developers are not the same, and so on, and so on. People are not pluggable assets.
  - webmaven 10y ago
    > People are not pluggable assets. Well, there is a countervailing force in that companies don't want every developer to be a SPOF, giving the company a "bus number" of one no matter who gets run over (the typical definition asks if any single developer is a SPOF, rather than every single developer being an irreplaceable special snowflake). That said, if you work for a company that leans too far the other way and values process over productivity, hammering every square peg until it can be wedged into any of the round holes (instead of enlarging the round holes to make them square), you may want to consider looking for a new employer.
cocktailpeanuts 10y ago
Aside from the judgment on whether the employer was terrible or not for making OP track the time, etc., if everyone tells you're slow, doesn't it occur to you that you may actually be bad? I finished reading the post but cannot figure out what OP is trying to say. The title doesn't match the content. At first it sounded like it was one of those rant posts exposing the employer for mistreating, but then at one point it sounds like OP understands that he is a bad developer (because everyone tells him he's slow), but then goes on to talk about whether it may be the manager and not him. And then ends with some random conclusion about nothing. It's almost like watching an episode of Seinfeld--it's a post about nothing. Then again, if a company hired someone who's so obviously bad that everyone thinks he's slow, it's their own fault and must be a bad company. Explains why they make him track time and all that stuff.
- MrUnderhill 10y ago
  The time tracking thing actually resonated quite well with me. Where I work, we also track time on very specific items (with JIRA/Tempo, which even includes a "stop watch" on each issue). How I dread logging the hours there! Especially if it's a day or two after the fact. The items will often be specific features to be developed. And so I sit there, with the time sheet (and 20/20 hindsight, of course) asking myself: "How could you possibly have spent that long finishing it? It had a low estimate! Better round down so they don't think I'm an idiot. Who in their right mind would pay someone XYZ to add a lowly checkbox in the corner? I wonder how many hours Bob logged for that radio button he worked on. Those guys outside have emptied half a street's garbage cans in the time it took me to look up this API." Of course, it's probably mostly in one's head. Like the author I don't really get negative remarks on performance, and consider myself a reasonably decent developer. But even so, the task of painstakingly journaling every half hour worked seems incredibly demotivating sometimes, for presumably no other reason than being a great time to second-guess everything you did.
  - cocktailpeanuts 10y ago
    I think it's because you're NOT a bad developer. The problem is, OP sounds like he is definitely a bad developer, and there's really no way around that.
elihu 10y ago
One way to look at it is that if some company is continuing to pay you to work for them, they must have determined that it was worth it to them. If management is putting pressure on you to produce more, it's because they want, say, a 3x return on their investment instead of a 2x return. By accepting a job from them, you're obligated to work diligently at a sustainable pace. You aren't obligated to worry about whether you're more productive than your peers. I posted a link to Beppo the road sweeper's monologue from Momo by Michael Ende in a thread on a time management story a few days ago, but I'll link to it again since it seems relevant: https://www.youtube.com/watch?v=8Q_JYYcBP2Q#t=15m05s https://www.youtube.com/watch?v=8Q_JYYcBP2Q#t=15m05s
- Mathnerd314 10y ago
  If management has capital to spend, they might be spending it on new hires to see which ones work out, and firing low performers such as yourself. The majority of states are at-will states so you could easily get laid off.
  - elihu 10y ago
    That is something to consider. There is a difference though between working harder because you're afraid that you'll be replaced by someone faster and cheaper and working harder because you're motivated by feelings of guilt and shame. I don't think either one is particularly healthy, but in the former case you can at least make a rational decision whether the job is worth enough to you to risk burning yourself out. It's also worth considering that not all developers are easy to replace, for various reasons. A lot of big companies aren't in a position to be choosy as long as their employees are reasonably competent and can do the work.
datf 10y ago
I have worked at many places, many dev jobs. I've worked with people shipping features faster and slower than me. But that's very subjective. Using it as a metric or even pointing it out doesn't make sense to me. I've been forced by managers to merge or even ship features that are half-way done. I have to agree with other people advising you to switch to another place. If you are working in a toxic environment, or you don't agree with or like how they handle the projects, then there are better places for you to be. Don't be afraid to pursue a better workplace environment if that's what matters to you. Also, talk to your colleagues. See if they feel or see things the same way. Once you realize you're not the only one in that position you'll feel better about moving on. Come to thing about it, a long time ago I worked at a place as a development team lead, and I saw management doing similar things to my team members as what you're describing. I confronted the owner about that, but things didn't change. I then advised my colleagues to look for something better and so did I (even though they always treated me great). And I'm happy to say ten years later we are all happy we left, and we all know we don't want to work somewhere like that again.
- sethammons 10y ago
  Plus one to talking to your colleagues. At my work, we started peer reviews that are anonymous. You request feedback from a pool of people. Those who give feedback talk on areas of strength and areas that need development. My imposter syndrome declined immensely after seeing some of the strengths listed from my peers with whome I work every day. I could agree with the areas of growth needed and it gave me focus for professional goals.
- AnneDev 10y ago
  Article OP here, it was supposed to be implied that this was a job I worked at in the past (the time tracking thing). I confronted management about the time tracking but it was one of my first jobs so I had little experience with that kind of thing. The job was a nightmare in so many different ways that the time tracking was the straw that broke the camel's back.
alkonaut 10y ago
Being a developer always means getting stuck on some trivial crap for a full day and going to bed angry. One simply makes up for it by those times when you create fantastic value in thirty minutes. You find the bug right away, or a new feature or deployment just falls into place smoothly. Software development is like solving math problems - it's not a continuously progressing process, no matter how much the agile priests want it to be. This developer sounds humble. That's the most important quality a developer can have. If one becomes too humble (impostor syndrome) then one needs an environment of more encouragement. That's the job of peers and managers. There are lots of bad developers. It's not unthinkable that this guy is a bad developer - but it's still the managers problem. Is he trained, mentored and encouraged enough?
- analog31 10y ago
  It helps to have a way to erase your brain before going to bed. ;-) For some, it's exercise, reading a book, working on a side project, cooking a nice meal. For me, it's playing music -- an activity that's intense enough that I simply have to exclude all thoughts of the problems at work, and engaged with people who don't give a rat's arse about my job.
- labster 10y ago
  And here I have thought hubris was one of the most important qualities of a good developer, along with impatience and laziness. Having a belief you can do it right is important to getting it right.
  - alkonaut 10y ago
    The humble bit is what makes sure that once you think you got it right, you actually got it right :)
- AnneDev 10y ago
  article OP here. I should mention that I'm a Lead Dev for a whole team (which is why I write this anonymously). I'm not sure if I'm humble. I sure as hell am not when I'm interviewing but I blame that on American culture. Thanks for the feedback! :)
nisse72 10y ago
I am also 'a little slow'. But the other side of that coin is that my code generally works correctly, and rarely (I wish I could say never) needs fixing later. My managers and customers know that my code will work 'as advertised'. My colleagues tell me they enjoy working in code I've written, because it isn't a mess and it feels logical and well organised. But hey, I'm a little slow. And in ~ 25 years of writing software for pay, only one manager I've worked for has ever had an issue with that.
ThomaszKrueger 10y ago
Perception is everything. You don't need to be good, you need to look good. On a tight schedule, deliver what was asked, and only that, even though you know other things are going to be necessary. When asked to estimate, try your best to give the longest you can get away with. Make it look or sound difficult. At the same time, do the hard work by yourself, figure things out on your own. When asked to account for your time, use the opportunity to be good at creative writing. Give the most flattering and awesome impression about the time you spent. Being competent is a pride for yourself only, for all others is whatever they want to see. Always act as if you are making less than you should. Act as, not be. Never stay working late, never work on weekends unless you are the one benefiting. The value you give yourself will be the value people will give you.
- cookiecaper 10y ago
  Yes. The fact is that for white-collar jobs, very few people can even tell whether or not you're competent. Some of your peers may, but I wouldn't count on it, and they're biased in favor of themselves anyway, so they're not objective resources. If you're lucky, your immediate manager may know how to tell if you're competent or not. Everyone else only has a very high-level concept of whether they think you've been doing what you're supposed to do. The optics on this must be controlled. You do not want to be one guy in the hierarchy away from getting shitcanned because everyone except your immediate boss thinks you don't finish enough tickets or whatever. Look better than everyone else. Employment is a popularity contest. To succeed in a career, do your job well enough that you don't get into trouble, and spend the rest of your energy on social and optical development. I must say, however, that "working overtime" (that is, sitting in your chair and looking fancy until 8pm at least 3 nights per week) is a near-necessity for someone looking to climb the ladder in most organizations. Since people don't know if you're doing a good job or not, the amount of time they see you in the office is a big component of their evaluation. They assume you are working if you are butt-in-chair. You need them to think you're a hard worker. You should never be the first one to leave unless you make sure everyone knows it's a special event for which you cleared PTO approval process, and you should be one of the last to leave at least 3/5 of the nights.
  - 10y ago
deleted 10y ago
[deleted]
rwallace 10y ago
> This isn’t an impostor syndrome. Sure it is. Impostor syndrome is defined as the state of affairs where your emotional assessment of your competence is lower than your actual competence. The definition does not depend on which aspect of the task is being discussed. "I can't write code" (when you can) and "I'm too slow" (when the people who appear faster, are doing it by just sweeping bugs under the carpet) are both impostor syndrome. I will add that by the sound of things, the reason you have impostor syndrome is because your previous bosses have been bullies, sadists and sociopaths who successfully accomplished their goal of damaging your morale for their own pleasure. This is sadly not a rare state of affairs, but it's not universal either. Never be reluctant to look for another job if your boss is an asshole.
- abannin 10y ago
  Such bold conclusions from 900 words and a single perspective. Isn't it possible that the author is, in fact, not good at the job?
  - zzzcpan 10y ago
    Is self doubt ever about being bad at something?
    - imagist 10y ago
      Yes, unless you believe that a) nobody is ever bad at anything, or b) nobody bad at something ever notices.
    - monochromatic 10y ago
      Sure, sometimes it is. When I doubt my career skills, I can (usually, eventually) recognize it as insecurity / impostor syndrome / whatever. When I doubt my dancing skills, it's a rational evaluation.
      - adventured 10y ago
        It sounds like what you're doing is accurately assessing your lack of dancing skills, not doubting your dancing ability. A hallmark of self-doubt is the nagging unknown, a questioning, a debate that goes on in one's head as to the real truth of the matter. I'd bet such a debate doesn't exist about your dancing given the rational part you mentioned. If it's actually a correct, accepted, rational evaluation, then what you have is self-fact: I can't dance well; rather than self-doubt: I'm not sure if I can dance well. The rational evaluation part eliminates the doubt once it's accepted, as you've arrived at a rock-solid conclusion.
MatekCopatek 10y ago
I've had similar self-doubt in the past, I considered myself fast but sloppy. I changed my opinion after a workshop on different team roles at my previous job. A lot of it was boring workshop fluff, but I loved the core message: that many personality traits aren't purely positive or negative. Perfectionists are nitpickers. Fast developers are sloppy. Experienced ones overthink stuff. Bleeding-edge evangelists ruin long-term stability etc. There are two sides to every coin. We tend to value traits we have (or desire) and judge people based on that, but it really depends on the team and the task. Need a quick-and-dirty prototype ASAP? Give it to the framework hipster. Planning architecture for a complex long-term project? Ask the boring slow guy with 20 years experience. Build teams with enough variety and try to solve problems through process. Don't scold the fast guy for being sloppy, give him tasks that require speed and solve bugs with better QA and tests. TL;DR: A damage dealer will beat a healer one on one, but that doesn't mean he's better. You need them both (plus a tank) to run a dungeon successfully.
- pizzacowboy 10y ago
  This is a great perspective. Although, sometimes, a poorly spec'ed tank is worth pretty much his weight in garbage. :)
- pducks32 10y ago
  I consider myself meticulous but slow. My coworker and I often talk about he differences and I always have wish I cared less about certain things and prioritized time more while he likes hat I focus heavily on maintainability and clarity.
  - rocqua 10y ago
    If traits have downsides and upsides, we get used to the upside and yearn for solving the downsides. In this yearning, we almost wish to give up our strengths so as to alleviate our weaknesses.
- devoply 10y ago
  Often the people judging us as good or bad are idiots that know nothing of what we do.
rwallace 10y ago
One more thing: always remember that it is not your job to protect your employer from the consequences of their bad decisions. It is their job to give you incentives that align with their own interests. If your employer is putting pressure on you to ship faster at the cost of sweeping a lot of bugs under the carpet, do that. If you think they're making a mistake, say once, calmly, that you think it would be worth spending more time upfront debugging. Once. After that, follow the priorities you are told to follow.
- st3v3r 10y ago
  It's not necessarily my job, but in many cases, there's still a good chance that I'm going to be the one yelled at, or have to deal with the consequences (having to work late nights to put out the fires caused by those decisions).
  - rwallace 10y ago
    Okay, but then it's important to understand your problem is not actually a technical one of bugs in the software, it's a political problem of your boss being a sadistic bully willing and able to ruin your life, plus a financial problem that you can't walk away from the job. Framing the problems correctly doesn't make them go away, but it does help focus your mind on things that have a chance of solving them.
PoarNeemn 10y ago
Its not that he was slow, the problem is that he was honest about the hours he worked.
Justsignedup 10y ago
I like to think of solutions and not problems, and costs: There are too many bugs in the code. Okay. Why? Well we don't have good testing set up. Why? Because time was not allotted for writing test code. Why? Because it was rushed. Conclusion: You either pay the cost up-front or after-the-fact. Either way. However if this is a constant thing then the real problem is: "You have too many features being built for the size of your team, either increase the size of the team, reduce features, or prepare for big problems." From personal experience I can say me working at "optimal" power, that is optimal sleep, no external life problems, not sick, generally very happy is maybe 30%-40% more productive. That seems like a lot, but if you need 500% the productivity, you ain't gonna get it by making a person feel like junk, not get needed rest (vacation / day off), not letting then handle family issues, etc. I can get a developer working at 100% more productivity, but only for a short amount of time, then they burn out which requires EVEN MORE rest time.
snarf21 10y ago
You may or may not be a bad developer. But lines of code has nothing to with being a good developer or providing value or solving problems. If your employer thinks all developers are equal and that they are just cogs in a machine, then that is not going to be a good place to work regardless of how fast you are. And you shouldn't beat yourself up about bad estimates. Everyone sucks at estimating. (Read "Thinking Fast and Slow") Which makes sense since we are estimating how long it will take us to make something we've never made before. Everything breaks down into day or week or weeks or month or.... You could also take 4 weeks to fully define every requirement and create tests for validation for a task that would have taken you two weeks. You are a bad developer if you keep making the same mistakes or if you don't spend anytime learning new concepts/languages/processes/etc. You are a bad developer if you approach your job as doing exactly what you're told and not caring or thinking about how your contribution is part of the bigger project.
ebiester 10y ago
There are two ways to look at this: it could be the environment, or he may have a rational reason to come to this conclusion. (Many developers are indeed slower than they could be.) Now, my major background task for 2016 and 2017 is trying to analyze how to become a better developer with myself as a guinea pig. I'm still putting things together, but "faster in the development environment of choice" is one stumbling block. These are the major issues I've found: 1. Being fast or slow only has a minor correlation with good code, but there are confounding issues. Good code takes different habits to write than bad code. 2. People who are fast at coding have an ingrained series of patterns on which they rely. They slow down when they are pulled out of their element, as can be expected. As such, there are meta-skills that contribute to speed, but a large portion of it is having a series of reliable patterns to solve the problem. It turns out most tasks are the same on the surface. Spend time getting those patterns at heart. 3. Fast developers have a deeper knowledge of the libraries around them. We underestimate the overhead of research, even with google. Spend some time exploring the corners of your libraries and frameworks and languages. If you work on the front end, you need to have the ins and outs of the client memorized. 4. In general, fast developers may not realize it, but they're methodical in how they approach problems. They have an internal checklist. Develop your own internal checklist. 5. Because they are fast, they have more confidence in developing tools that speed up the general issues that slow every developer down. (setting up environments, test data, and the like.) Laziness, it turns out,b is as much an byproduct as a cause. If you are slow, the ROI on developing tools might indeed be outside the timeframe of efficiency. Work on getting faster, and you will see more opportunities to consolidate your work. I'm still working out the solutions of how to teach this in a generalizable fashion and how to back this up with research, so don't take these as gospel and I'd be particularly interested in fast programmers who have alternative perspectives.
al2o3cr 10y ago
Management often assumes that they did their job when they handed in specs. And I often assume that there is nothing else for them to do. I can't say for certain that you're a bad developer, but if your management thinks throwing specs over the wall is "doing their job" they ARE bad at theirs. I'd argue that you fail your part of the job in that case if you DON'T have any questions. As for the slipping estimates, are you part of the process that generates them? If not, it's back into "your managers are bad at their jobs" territory.
bArray 10y ago
Some people write solid code slowly and some people write sloppy code fast. Of course every variant of those exists too. A good programmer would probably pay as much technical debt as early as possible.
belvoran 10y ago
For the last 15 years I was always slow, bad, and pessimistic. In fact I was fast, good, and realistic. However in the companies I was working at, the promoted guys were always writing buggy code, and really didn't understand what was going on. They even didn't want to understand that. They were promoted, and not me. Why? Because the speed was what there managers were promoted for. So they wanted to surround themselves with similar stupid-but-fast programmers. This way they all were promoted, got bonuses, and they were one brainless corporation family. I wanted to make some good work, and understand why something works this, or other way. And one day I gave up. It was hard to hear all the time something like "you are too pessimistic, why you always say that we cannot build the Tardis in a month?", or "You are too slow, you see that guy in the corner? He is ten times faster then the whole team (and he is happy working in an open space). And now the whole team will be fixing the thousands of failing tests (caused by this guy) for the next six months. Because if they will be red, I won't get the yearly bonus.". The latter is real. So I don't care anymore. My side projects are opposite. So I build them slowly. Very slowly. And I learn all the things around them.
Bahamut 10y ago
The labels of good/bad developer are not useful - just as we try to optimize the perf of our code, we should be focused on optimizing the things we can. For example, figuring out some answers to questions like "How can I get to this conclusion faster on figuring out bugs like this", or "How can I figure out the optimal architecture for this feature faster?" Putting things in front of us that are in our control and actionable is the best we can do. One has to break the block of being afraid of failure - we all fail at various tasks. The important part is how we respond to this failures.
kevin_thibedeau 10y ago
Polish the resume and bail out. You're working for Bill Lumbergh. You can't win against that sort of managerial talent.
loup-vaillant 10y ago
I got the "you're a bit slow" once. Which was funny, because I was very focused and felt very productive at that time —more than ever before. Plus, some of my code allowed a business expert to contribute directly, which made us even faster. I have since realised it had nothing to do with my actual performance. It was a people thing.
- Noumenon72 10y ago
  Please elaborate on the people thing.
  - loup-vaillant 10y ago
    During my job interview, I was told we were going to be equals. Like, explicitly. He was older, and came to the project earlier, so I still deferred to him. Nevertheless, I treated him like a peer. Turned out he wanted to be the boss —that was made official 2 months after my arrival. On my very first week, he started to make disparaging comments under the guise of joke (or were those real jokes?). Those soon occurred daily. Sometimes in front of the client, who (surprise!) eventually lost trust in me. If this was my only experience, I would have thought it was me. But I have since received enough external validation about my skills (people looking up to me, actual results…) to know better. For some reason, the guy could not stand me, so he got rid of me. Another small detail: he never smiled at me in the morning when we shook hands to say hello. He did smile at everyone else.
dunkelheit 10y ago
One general piece of advice that stuck with me after reading "Feeling Good: The New Mood Therapy" (a cognitive therapy book) is to refrain from thinking in inherent categories about myself. Thinking "I'm a slow developer" is just depressing and sad - there is nothing much you can do about your inherent flaw. By contrast, thinking "I've done this task slowly" puts you in a problem-solving mood. Something like "Wow, I've actually shipped, that's great! Now, it took me a bit more time than I've anticipated. Does it really matter? If it does, what can I do about it?" Also, a lot of this is just management trying to put pressure on the devs using methods more appropriate for a kindergarten. I vividly remember my former boss telling me "you are going to put down the team and have a bad conscience if you don't finish this feature on time" (an arbitrary deadline caused by a looming performance review). He was a good boss, but I would have more appreciated an honest "look, I'm trying to get you a raise so finishing this feature by this date is in our mutual interest" without any kind of moralizing shit.
GoToRO 10y ago
Most people cut corners. They deliver crap, fast. But when you add the time needed to debug that crap, to refactor it, was it really fast? Of course managers don't track time over the whole life of a feature... - So it says in your CV that you are quick at math. - Yes. Yes I am. - How much is 23 times 14. - 7! - That's not even close! - No. But it was quick!
pmarreck 10y ago
I was challenged by my bosses at my last job because they were concerned about overall team productivity (including mine... mainly because I spent some additional time refactoring and creating better testing tools, because those were necessary and coworkers reported them as cool and labor-saving) and they put us in a "bataan death march" mode without a definite ending (...) and I pushed back and said this is bullshit because what these metrics I took say is that we need to be paying down some tech debt, stat. I ended up leaving. Sometimes, the job is too good for you, and sometimes you are too good for the job.
nope_42 10y ago
Having read some of the comments in here I'm surprised to see that no one has mentioned how the co-workers reporting their time are lying and this developer isn't. If you worked on a feature for an hour and stared off into space for another hour you report that the feature took two hours. If you took 30 minutes to write an email you certainly don't report that; you move time around to make it look better. This behavior is totally normal in this industry and if you get put in a situation like that you have to do the same. No one can concentrate for 40 hours every week on development without getting burned out. The reality is most people are probably lucky to get 20 hours of productive work done a week.
- Sammi 10y ago
  I do some of my best programming while I'm staring out the window or getting coffee or sitting on the toilet.
  - tdy721 10y ago
    Me too, but it still feels cheating when I bill for that time.
phkahler 10y ago
>> Bathroom breaks were consider unproductive, talking to co-workers was considered unproductive, and doing any kind of research was pointless unless we could bill a customer. That is simply bullshit. Don't take anything they say seriously except the broadest interpretation of what the project is. It sounds like the writer has something north of basic competence. In that case, just do your job mostly your way and don't give a fuck what the others think. If THEY don't think you're worth your price they won't keep paying you. It's really as simple as that. And if you do find yourself out on the street then you can sit back and try to decide how to partition the failure between yourself and the company. If there's any blame you can clearly put on yourself then work on that. Otherwise just assume it's them and move on. The longer you work in the field, the more you can assume you don't suck regardless of what people appear to think. In other words, actions speak louder than words or even company policy. If they're keeping you it's because you're valuable regardless of what they say.
edblarney 10y ago
"I mean, how could someone spend several hours trying to debug a table that looked one way on Firefox and one way on Chrome?" Because HTML and it's various implementations/versions are a Byzantine mess. 'Web development' is not so much development ... it's about knowing a myriad of little, innocuous details regarding various platform, api quirks, toolchain bits etc.. The 'development' part of web-dev is usually quite straight forward - you're not doing complex AI etc.. And fyi - development is 90% struggling through things you don't understand, bugs, hiccups etc.. A good chunk of the code you write like English. It's all about working through the pain points, making 'aha' realizations about how you structured something, or about some crazy API quirk. That's the job.
j45 10y ago
In a way, most people should be doing bad work today.. looking 5 years back.
ilaksh 10y ago
Seems like people are misinterpreting what he is saying. He is NOT saying he really thinks he is slow. I think this is a polite and less direct way of saying that constant pressure to increase 'productivity' is counter-productive in terms of outcomes and harmful to employees psychologically.
orbitingpluto 10y ago
I've told this story before, so here is the short version. I replaced $girl in a sysadmin/programming role that would get used by other employees. According to my supervisor, she was always far more productive than me. He'd ask for an estimate of how long something would take and he'd always say, "That's too long. $girl could do it half the time." Well, because it was my first tech job company, I sort of had impostor syndrome because of him but also thought of a way to test it out. One job we often had would get programmed from scratch several times a year and take about 2 or 3 hours to do. I cludged it into a simple framework where I could just edit the XML after the other employees started to use it. So when he asked me how long it was going to take before people could start using it I said thirty seconds. "That's too long... $girl could do it 15..., wait, what?"
- effie 10y ago
  Wow, that had to crack you up laughing:)
AnneDev 10y ago
As the OP of the article, can someone tell me what I did wrong? https://news.ycombinator.com/item?id=13281186 https://news.ycombinator.com/item?id=13281186

177 points by passenger 10y ago

I'd suggest trying to focus more on using tools related to building reports on code coverage and code complexity during your day to day development. If you lean more towards a test driven approach backed with trackable metrics for code quality, I think you might have more confidence in your day to day development and ultimately be more productive.

amriksohata 10y ago
You do realise even the founder of TDD doesn't back it anymore and code coverage is a very poor metric, your words sound like a senior developer from 2010. If he's a bad developer the best he can do is read up on SOLID principles and read a book like Clean Code with good examples of how to write code.
- amriksohata 10y ago
  That said, from the article it just sounds like he's worked for shitty companies that don't understand the value of not writing code twice
- jghn 10y ago
  "You do realise even the founder of TDD doesn't back it anymore" I ask this out of genuine curiosity but do you have a cite for this? Being fairly anti-TDD myself it'd be good to keep this factoid in my pocket.
- matthewmacleod 10y ago
  TDD is still a fine tool and the field hasn't moved on so much in 6 years that it's a stupid suggestion. It's a perfectly viable tool for helping to maintain output quality - like all other tools it might not work for everybody, or it might have to be applied carefully. But I wouldn't advise anyone to cargo cult the apostasy of a single proponent.
- emmelaich 10y ago
  If you're referring to https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847/ https://www.facebook.com/notes/kent-beck/rip-tdd/75084019494... he was being sarcastic. But he also has said it can be over-done. Which is not surprising, because everything that can be done can be over-done.

auggierose 10y ago

I am not sure what this post is about. Just realise, when you are working for somebody else, of course they would like repeatable good performance from you. Some people are able to deliver this better than others. In my experience, thinking through a problem thoroughly and not giving a shit what others think is the most comfortable and most efficient way to work. Not even sure why you would consider working for somebody who stops you from going to the bathroom.

zzzcpan 10y ago
Also not sure what the author is trying to say. But sounds like a really bad management is trying to pressure him. He won't be able to work like that for long. Probably better to start looking for another job and without a time tracking.

exratione 10y ago

Everyone has been put in the position of coming to a dead halt on some aspect of the work that just won't yield. Or at least not for the combination of you, your knowledge, and your resources at that given time. This never goes away. Signs of maturity as a developer involve how you deal with the existence of this phenomenon. E.g. box your time, know when to seek alternatives, and know how to find solutions that exist already, and especially know when to pull in help - and how to find useful help in your network. The driving overall concern is avoiding points of grinding minimal efficiency for individuals, and in near all cases that can be avoided via some combination of simple strategies, even when you are the only person on your own personal project. Development is such a huge space that no two people will overlap completely in skills and experience on a team, and pulling in other people to alleviate your dead ends is a part of how you learn specifics needed to avoid that dead end in the future. But it is knowing to pull people in or seek another path that is the important part, not the specifics. Working to an absolute dead end is only useful in the sense that you then understand better the incentive to avoid doing it again if you can. An alternative view on the same problem space: https://www.exratione.com/2016/01/paid-a-great-deal-to-be-terrible-at-development-most-of-the-time/ https://www.exratione.com/2016/01/paid-a-great-deal-to-be-te...

a3n 10y ago
> box your time What exactly does that mean. I'm not saying this isn't a real thing (I really have no idea), but the only time I've heard the phrase used in person was by people who get ahead by posturing. When someone uses it sincerely, what do they mean? What does it look like, as opposed to not boxing your time? What specifically does it solve?
- tbirrell 10y ago
  I've always understood it to mean that you put an arbitrary deadline on the issue. ie "If I have not solved this by 12:15, I'll get help/move on". I'm not sure why it's called "boxing time" and I could be totally off base, but it makes sense.
- RandomOpinion 10y ago
  >When someone uses it sincerely, what do they mean? What does it look like, as opposed to not boxing your time? What specifically does it solve? A technical analogy would be depth-first search of a solution space, e.g. in a simple chess AI. If the search has a cut-off depth = deterministically bounded length of search time = time-boxed If the search does not a cut-off depth = unbounded (potentially infinite) length of search time = not time-boxed

jeremiep 10y ago

You could change jobs. An employer tracking your activities to the minute sounds like a cancerous work place to begin with. Bad employers are also a thing, and is much more frequent than most people realize. They usually drown you in tools and processes along the way and without much development experience its hard to tell whether they're bad or you are. You're going to hear about Agile, TDD, code metrics and whatnot. Its all superficial at best and those promoting them don't usually have quality products on their hands to begin with, or have codebases much larger than actually needed. At least from my experience its that way. Its best to find an employer who can help you grow instead of fitting you in a box.

rplst8 10y ago
I think you are lumping things together where they don't belong. Processes and tools have places. As I've posted previously on the topic, some industries have strict quality standards, and the tools and processes are there to find and prevent bugs from making into fielded systems. These process can an do work, but don't always apply to a basic website or CRUD webapp.
- jeremiep 10y ago
  Oh definitely, I was referring to things like Jira, Scrumm and the likes rather than industry standards.
  - ConnorLeet 10y ago
    Tools to help with a process, not to define the process.

0xdeadbeefbabe 10y ago

I suppose if you help someone do something they could not do themselves then you are actually a good developer, something like writing minecraft. It seems like your criteria for being a good developer is more complex, maybe even hopelessly more complex. Why don't you try charging them 10 cents for each trip through your code? Lawyers do that, and feel like it's okay.

transfire 10y ago

Good software requires teams, and teams will always vary in the member's skill levels. Some programmers are better than others -- that's just a fact of life. But even if you are not one of the best coders, that doesn't mean you shouldn't be a coder or that you shouldn't be considered a valuable member of a team, so long as you provide a meaningful contribution. You may get paid less, but that's okay. You shouldn't beat yourself up over it. Do you enjoy the work? Do you at least get stuff done, even if it is not as much as your coworker in the same period of time? Then your okay. And that's okay. You just need to find the right niche. Not every coding job is with a startup or contract firm that needs to pump out the code a mile per minute.

urathai 10y ago
I agree! You should always remember that (about) half of the people perform under the average and there is no real way around that. Not everyone can reach the top and that is something I think you need to accept at times.

trjordan 10y ago

Estimations are a game we play. To understand how good you are, you need to figure out what's happening with the business and understand the impact you're having there. For a small company, this is probably the rate at which you ship features. Good developers ship enough that there's pressure to constantly explain the improvement to sales / marketing. For a larger company, this is probably a user metric. Are this things you're doing moving the needle on logins, time on site, repeat visits? You should understand what areas of the product are high value, and which are experimental. You should spend your time converting experimental features to high value features. Polish and edge cases. For a bigco, this is probably scaling metrics, like page load time and uptime. You should have clear targets you're working against and be able to prioritize against that target. Numbers are easy to show results against. Anybody can be fast against sprint points. You need to understand what the business goal is and play to your strengths against that goal.

probinso 10y ago

Pay has little to do with throughput. Pay is an arbitrary number that you and your handler select from the ether. This decision is often made well before there is any chance of measuring your productivity. If you think the number was poorly selected, just know it is. I found time tracking tools to be hugely beneficial. It changed my focus, and forced me more aware of what I was working on. I am, however, a slow developer sometimes. It is just who I am. I found that often employers look for 'smart' candidates, instead of SMEs. This is their fault. If they were interested in / could afford a subject matter expert (SME) then you wouldn't likely be working there. If you are an SME, then you will likely produce results/prototypes far faster than others. Smart people take time to learn, thats how they got there.

tbirrell 10y ago
SME = Subject Matter Expert (if google is to be believed).
- nishs 10y ago
  Yes. Also defined in author's last paragraph.
  - Noumenon72 10y ago
    I saw it, but only because I had started skipping through his post knowing it wouldn't make sense unless he explained SME. Poor communication habit.
    - probinso 10y ago
      thanks for noticing! :)
- probinso 10y ago
  google is to be believed

karmajunkie 10y ago

There are a lot of ways to dice up performance as a developer, and while some are clearly bad, like LOC counts, others are merely different from each other. Is it better to ship a feature faster? All things being equal, sure—but all things are rarely equal. All bugs aren't created equal, nor features, nor design requirements. Nor are the skills needed to handle any or all of those things distributed equally amongst developers. I was on a team once where my diagnostic skills put me near the top of the stack for being given hard-to-find bugs. What that meant was that sometimes I would ship one commit a week while tracking down several difficult issues. Does that make me a bad developer? A slow developer? Or are those even valuable distinctions in this context? Rather than trying to be better than everyone (anyone?) else, try to be better than you yourself were last week, or last month, or last year. That's the only consistent variable one has across all the kinds of tasks we are called to perform in this role.

rplst8 10y ago
>I was on a team once where my diagnostic skills put me near the top of the stack for being given hard-to-find bugs. What that meant was that sometimes I would ship one commit a week while tracking down several difficult issues. This. A good management team will recognize these skills in people and assign them appropriate work. All people are not the same, that's why we have developers and doctors and fireman. All developers are not the same, that's why we have backend, frontend, Java, C++, etc. All backend developers are not the same, and so on, and so on. People are not pluggable assets.
- webmaven 10y ago
  > People are not pluggable assets. Well, there is a countervailing force in that companies don't want every developer to be a SPOF, giving the company a "bus number" of one no matter who gets run over (the typical definition asks if any single developer is a SPOF, rather than every single developer being an irreplaceable special snowflake). That said, if you work for a company that leans too far the other way and values process over productivity, hammering every square peg until it can be wedged into any of the round holes (instead of enlarging the round holes to make them square), you may want to consider looking for a new employer.

cocktailpeanuts 10y ago

Aside from the judgment on whether the employer was terrible or not for making OP track the time, etc., if everyone tells you're slow, doesn't it occur to you that you may actually be bad? I finished reading the post but cannot figure out what OP is trying to say. The title doesn't match the content. At first it sounded like it was one of those rant posts exposing the employer for mistreating, but then at one point it sounds like OP understands that he is a bad developer (because everyone tells him he's slow), but then goes on to talk about whether it may be the manager and not him. And then ends with some random conclusion about nothing. It's almost like watching an episode of Seinfeld--it's a post about nothing. Then again, if a company hired someone who's so obviously bad that everyone thinks he's slow, it's their own fault and must be a bad company. Explains why they make him track time and all that stuff.

MrUnderhill 10y ago
The time tracking thing actually resonated quite well with me. Where I work, we also track time on very specific items (with JIRA/Tempo, which even includes a "stop watch" on each issue). How I dread logging the hours there! Especially if it's a day or two after the fact. The items will often be specific features to be developed. And so I sit there, with the time sheet (and 20/20 hindsight, of course) asking myself: "How could you possibly have spent that long finishing it? It had a low estimate! Better round down so they don't think I'm an idiot. Who in their right mind would pay someone XYZ to add a lowly checkbox in the corner? I wonder how many hours Bob logged for that radio button he worked on. Those guys outside have emptied half a street's garbage cans in the time it took me to look up this API." Of course, it's probably mostly in one's head. Like the author I don't really get negative remarks on performance, and consider myself a reasonably decent developer. But even so, the task of painstakingly journaling every half hour worked seems incredibly demotivating sometimes, for presumably no other reason than being a great time to second-guess everything you did.
- cocktailpeanuts 10y ago
  I think it's because you're NOT a bad developer. The problem is, OP sounds like he is definitely a bad developer, and there's really no way around that.

elihu 10y ago

One way to look at it is that if some company is continuing to pay you to work for them, they must have determined that it was worth it to them. If management is putting pressure on you to produce more, it's because they want, say, a 3x return on their investment instead of a 2x return. By accepting a job from them, you're obligated to work diligently at a sustainable pace. You aren't obligated to worry about whether you're more productive than your peers. I posted a link to Beppo the road sweeper's monologue from Momo by Michael Ende in a thread on a time management story a few days ago, but I'll link to it again since it seems relevant: https://www.youtube.com/watch?v=8Q_JYYcBP2Q#t=15m05s https://www.youtube.com/watch?v=8Q_JYYcBP2Q#t=15m05s

Mathnerd314 10y ago
If management has capital to spend, they might be spending it on new hires to see which ones work out, and firing low performers such as yourself. The majority of states are at-will states so you could easily get laid off.
- elihu 10y ago
  That is something to consider. There is a difference though between working harder because you're afraid that you'll be replaced by someone faster and cheaper and working harder because you're motivated by feelings of guilt and shame. I don't think either one is particularly healthy, but in the former case you can at least make a rational decision whether the job is worth enough to you to risk burning yourself out. It's also worth considering that not all developers are easy to replace, for various reasons. A lot of big companies aren't in a position to be choosy as long as their employees are reasonably competent and can do the work.

datf 10y ago

I have worked at many places, many dev jobs. I've worked with people shipping features faster and slower than me. But that's very subjective. Using it as a metric or even pointing it out doesn't make sense to me. I've been forced by managers to merge or even ship features that are half-way done. I have to agree with other people advising you to switch to another place. If you are working in a toxic environment, or you don't agree with or like how they handle the projects, then there are better places for you to be. Don't be afraid to pursue a better workplace environment if that's what matters to you. Also, talk to your colleagues. See if they feel or see things the same way. Once you realize you're not the only one in that position you'll feel better about moving on. Come to thing about it, a long time ago I worked at a place as a development team lead, and I saw management doing similar things to my team members as what you're describing. I confronted the owner about that, but things didn't change. I then advised my colleagues to look for something better and so did I (even though they always treated me great). And I'm happy to say ten years later we are all happy we left, and we all know we don't want to work somewhere like that again.

sethammons 10y ago
Plus one to talking to your colleagues. At my work, we started peer reviews that are anonymous. You request feedback from a pool of people. Those who give feedback talk on areas of strength and areas that need development. My imposter syndrome declined immensely after seeing some of the strengths listed from my peers with whome I work every day. I could agree with the areas of growth needed and it gave me focus for professional goals.
AnneDev 10y ago
Article OP here, it was supposed to be implied that this was a job I worked at in the past (the time tracking thing). I confronted management about the time tracking but it was one of my first jobs so I had little experience with that kind of thing. The job was a nightmare in so many different ways that the time tracking was the straw that broke the camel's back.

alkonaut 10y ago

Being a developer always means getting stuck on some trivial crap for a full day and going to bed angry. One simply makes up for it by those times when you create fantastic value in thirty minutes. You find the bug right away, or a new feature or deployment just falls into place smoothly. Software development is like solving math problems - it's not a continuously progressing process, no matter how much the agile priests want it to be. This developer sounds humble. That's the most important quality a developer can have. If one becomes too humble (impostor syndrome) then one needs an environment of more encouragement. That's the job of peers and managers. There are lots of bad developers. It's not unthinkable that this guy is a bad developer - but it's still the managers problem. Is he trained, mentored and encouraged enough?

analog31 10y ago
It helps to have a way to erase your brain before going to bed. ;-) For some, it's exercise, reading a book, working on a side project, cooking a nice meal. For me, it's playing music -- an activity that's intense enough that I simply have to exclude all thoughts of the problems at work, and engaged with people who don't give a rat's arse about my job.
labster 10y ago
And here I have thought hubris was one of the most important qualities of a good developer, along with impatience and laziness. Having a belief you can do it right is important to getting it right.
- alkonaut 10y ago
  The humble bit is what makes sure that once you think you got it right, you actually got it right :)
AnneDev 10y ago
article OP here. I should mention that I'm a Lead Dev for a whole team (which is why I write this anonymously). I'm not sure if I'm humble. I sure as hell am not when I'm interviewing but I blame that on American culture. Thanks for the feedback! :)

nisse72 10y ago

I am also 'a little slow'. But the other side of that coin is that my code generally works correctly, and rarely (I wish I could say never) needs fixing later. My managers and customers know that my code will work 'as advertised'. My colleagues tell me they enjoy working in code I've written, because it isn't a mess and it feels logical and well organised. But hey, I'm a little slow. And in ~ 25 years of writing software for pay, only one manager I've worked for has ever had an issue with that.

ThomaszKrueger 10y ago

Perception is everything. You don't need to be good, you need to look good. On a tight schedule, deliver what was asked, and only that, even though you know other things are going to be necessary. When asked to estimate, try your best to give the longest you can get away with. Make it look or sound difficult. At the same time, do the hard work by yourself, figure things out on your own. When asked to account for your time, use the opportunity to be good at creative writing. Give the most flattering and awesome impression about the time you spent. Being competent is a pride for yourself only, for all others is whatever they want to see. Always act as if you are making less than you should. Act as, not be. Never stay working late, never work on weekends unless you are the one benefiting. The value you give yourself will be the value people will give you.

cookiecaper 10y ago
Yes. The fact is that for white-collar jobs, very few people can even tell whether or not you're competent. Some of your peers may, but I wouldn't count on it, and they're biased in favor of themselves anyway, so they're not objective resources. If you're lucky, your immediate manager may know how to tell if you're competent or not. Everyone else only has a very high-level concept of whether they think you've been doing what you're supposed to do. The optics on this must be controlled. You do not want to be one guy in the hierarchy away from getting shitcanned because everyone except your immediate boss thinks you don't finish enough tickets or whatever. Look better than everyone else. Employment is a popularity contest. To succeed in a career, do your job well enough that you don't get into trouble, and spend the rest of your energy on social and optical development. I must say, however, that "working overtime" (that is, sitting in your chair and looking fancy until 8pm at least 3 nights per week) is a near-necessity for someone looking to climb the ladder in most organizations. Since people don't know if you're doing a good job or not, the amount of time they see you in the office is a big component of their evaluation. They assume you are working if you are butt-in-chair. You need them to think you're a hard worker. You should never be the first one to leave unless you make sure everyone knows it's a special event for which you cleared PTO approval process, and you should be one of the last to leave at least 3/5 of the nights.
- 10y ago

deleted 10y ago

[deleted]

rwallace 10y ago

> This isn’t an impostor syndrome. Sure it is. Impostor syndrome is defined as the state of affairs where your emotional assessment of your competence is lower than your actual competence. The definition does not depend on which aspect of the task is being discussed. "I can't write code" (when you can) and "I'm too slow" (when the people who appear faster, are doing it by just sweeping bugs under the carpet) are both impostor syndrome. I will add that by the sound of things, the reason you have impostor syndrome is because your previous bosses have been bullies, sadists and sociopaths who successfully accomplished their goal of damaging your morale for their own pleasure. This is sadly not a rare state of affairs, but it's not universal either. Never be reluctant to look for another job if your boss is an asshole.

abannin 10y ago
Such bold conclusions from 900 words and a single perspective. Isn't it possible that the author is, in fact, not good at the job?
- zzzcpan 10y ago
  Is self doubt ever about being bad at something?
  - imagist 10y ago
    Yes, unless you believe that a) nobody is ever bad at anything, or b) nobody bad at something ever notices.
  - monochromatic 10y ago
    Sure, sometimes it is. When I doubt my career skills, I can (usually, eventually) recognize it as insecurity / impostor syndrome / whatever. When I doubt my dancing skills, it's a rational evaluation.
    - adventured 10y ago
      It sounds like what you're doing is accurately assessing your lack of dancing skills, not doubting your dancing ability. A hallmark of self-doubt is the nagging unknown, a questioning, a debate that goes on in one's head as to the real truth of the matter. I'd bet such a debate doesn't exist about your dancing given the rational part you mentioned. If it's actually a correct, accepted, rational evaluation, then what you have is self-fact: I can't dance well; rather than self-doubt: I'm not sure if I can dance well. The rational evaluation part eliminates the doubt once it's accepted, as you've arrived at a rock-solid conclusion.

MatekCopatek 10y ago

I've had similar self-doubt in the past, I considered myself fast but sloppy. I changed my opinion after a workshop on different team roles at my previous job. A lot of it was boring workshop fluff, but I loved the core message: that many personality traits aren't purely positive or negative. Perfectionists are nitpickers. Fast developers are sloppy. Experienced ones overthink stuff. Bleeding-edge evangelists ruin long-term stability etc. There are two sides to every coin. We tend to value traits we have (or desire) and judge people based on that, but it really depends on the team and the task. Need a quick-and-dirty prototype ASAP? Give it to the framework hipster. Planning architecture for a complex long-term project? Ask the boring slow guy with 20 years experience. Build teams with enough variety and try to solve problems through process. Don't scold the fast guy for being sloppy, give him tasks that require speed and solve bugs with better QA and tests. TL;DR: A damage dealer will beat a healer one on one, but that doesn't mean he's better. You need them both (plus a tank) to run a dungeon successfully.

pizzacowboy 10y ago
This is a great perspective. Although, sometimes, a poorly spec'ed tank is worth pretty much his weight in garbage. :)
pducks32 10y ago
I consider myself meticulous but slow. My coworker and I often talk about he differences and I always have wish I cared less about certain things and prioritized time more while he likes hat I focus heavily on maintainability and clarity.
- rocqua 10y ago
  If traits have downsides and upsides, we get used to the upside and yearn for solving the downsides. In this yearning, we almost wish to give up our strengths so as to alleviate our weaknesses.
devoply 10y ago
Often the people judging us as good or bad are idiots that know nothing of what we do.

rwallace 10y ago

One more thing: always remember that it is not your job to protect your employer from the consequences of their bad decisions. It is their job to give you incentives that align with their own interests. If your employer is putting pressure on you to ship faster at the cost of sweeping a lot of bugs under the carpet, do that. If you think they're making a mistake, say once, calmly, that you think it would be worth spending more time upfront debugging. Once. After that, follow the priorities you are told to follow.

st3v3r 10y ago
It's not necessarily my job, but in many cases, there's still a good chance that I'm going to be the one yelled at, or have to deal with the consequences (having to work late nights to put out the fires caused by those decisions).
- rwallace 10y ago
  Okay, but then it's important to understand your problem is not actually a technical one of bugs in the software, it's a political problem of your boss being a sadistic bully willing and able to ruin your life, plus a financial problem that you can't walk away from the job. Framing the problems correctly doesn't make them go away, but it does help focus your mind on things that have a chance of solving them.

PoarNeemn 10y ago

Its not that he was slow, the problem is that he was honest about the hours he worked.

Justsignedup 10y ago

I like to think of solutions and not problems, and costs: There are too many bugs in the code. Okay. Why? Well we don't have good testing set up. Why? Because time was not allotted for writing test code. Why? Because it was rushed. Conclusion: You either pay the cost up-front or after-the-fact. Either way. However if this is a constant thing then the real problem is: "You have too many features being built for the size of your team, either increase the size of the team, reduce features, or prepare for big problems." From personal experience I can say me working at "optimal" power, that is optimal sleep, no external life problems, not sick, generally very happy is maybe 30%-40% more productive. That seems like a lot, but if you need 500% the productivity, you ain't gonna get it by making a person feel like junk, not get needed rest (vacation / day off), not letting then handle family issues, etc. I can get a developer working at 100% more productivity, but only for a short amount of time, then they burn out which requires EVEN MORE rest time.

snarf21 10y ago

You may or may not be a bad developer. But lines of code has nothing to with being a good developer or providing value or solving problems. If your employer thinks all developers are equal and that they are just cogs in a machine, then that is not going to be a good place to work regardless of how fast you are. And you shouldn't beat yourself up about bad estimates. Everyone sucks at estimating. (Read "Thinking Fast and Slow") Which makes sense since we are estimating how long it will take us to make something we've never made before. Everything breaks down into day or week or weeks or month or.... You could also take 4 weeks to fully define every requirement and create tests for validation for a task that would have taken you two weeks. You are a bad developer if you keep making the same mistakes or if you don't spend anytime learning new concepts/languages/processes/etc. You are a bad developer if you approach your job as doing exactly what you're told and not caring or thinking about how your contribution is part of the bigger project.

ebiester 10y ago

There are two ways to look at this: it could be the environment, or he may have a rational reason to come to this conclusion. (Many developers are indeed slower than they could be.) Now, my major background task for 2016 and 2017 is trying to analyze how to become a better developer with myself as a guinea pig. I'm still putting things together, but "faster in the development environment of choice" is one stumbling block. These are the major issues I've found: 1. Being fast or slow only has a minor correlation with good code, but there are confounding issues. Good code takes different habits to write than bad code. 2. People who are fast at coding have an ingrained series of patterns on which they rely. They slow down when they are pulled out of their element, as can be expected. As such, there are meta-skills that contribute to speed, but a large portion of it is having a series of reliable patterns to solve the problem. It turns out most tasks are the same on the surface. Spend time getting those patterns at heart. 3. Fast developers have a deeper knowledge of the libraries around them. We underestimate the overhead of research, even with google. Spend some time exploring the corners of your libraries and frameworks and languages. If you work on the front end, you need to have the ins and outs of the client memorized. 4. In general, fast developers may not realize it, but they're methodical in how they approach problems. They have an internal checklist. Develop your own internal checklist. 5. Because they are fast, they have more confidence in developing tools that speed up the general issues that slow every developer down. (setting up environments, test data, and the like.) Laziness, it turns out,b is as much an byproduct as a cause. If you are slow, the ROI on developing tools might indeed be outside the timeframe of efficiency. Work on getting faster, and you will see more opportunities to consolidate your work. I'm still working out the solutions of how to teach this in a generalizable fashion and how to back this up with research, so don't take these as gospel and I'd be particularly interested in fast programmers who have alternative perspectives.

al2o3cr 10y ago

Management often assumes that they did their job when they handed in specs. And I often assume that there is nothing else for them to do. I can't say for certain that you're a bad developer, but if your management thinks throwing specs over the wall is "doing their job" they ARE bad at theirs. I'd argue that you fail your part of the job in that case if you DON'T have any questions. As for the slipping estimates, are you part of the process that generates them? If not, it's back into "your managers are bad at their jobs" territory.

bArray 10y ago

Some people write solid code slowly and some people write sloppy code fast. Of course every variant of those exists too. A good programmer would probably pay as much technical debt as early as possible.

belvoran 10y ago

For the last 15 years I was always slow, bad, and pessimistic. In fact I was fast, good, and realistic. However in the companies I was working at, the promoted guys were always writing buggy code, and really didn't understand what was going on. They even didn't want to understand that. They were promoted, and not me. Why? Because the speed was what there managers were promoted for. So they wanted to surround themselves with similar stupid-but-fast programmers. This way they all were promoted, got bonuses, and they were one brainless corporation family. I wanted to make some good work, and understand why something works this, or other way. And one day I gave up. It was hard to hear all the time something like "you are too pessimistic, why you always say that we cannot build the Tardis in a month?", or "You are too slow, you see that guy in the corner? He is ten times faster then the whole team (and he is happy working in an open space). And now the whole team will be fixing the thousands of failing tests (caused by this guy) for the next six months. Because if they will be red, I won't get the yearly bonus.". The latter is real. So I don't care anymore. My side projects are opposite. So I build them slowly. Very slowly. And I learn all the things around them.

Bahamut 10y ago

The labels of good/bad developer are not useful - just as we try to optimize the perf of our code, we should be focused on optimizing the things we can. For example, figuring out some answers to questions like "How can I get to this conclusion faster on figuring out bugs like this", or "How can I figure out the optimal architecture for this feature faster?" Putting things in front of us that are in our control and actionable is the best we can do. One has to break the block of being afraid of failure - we all fail at various tasks. The important part is how we respond to this failures.

kevin_thibedeau 10y ago

Polish the resume and bail out. You're working for Bill Lumbergh. You can't win against that sort of managerial talent.

loup-vaillant 10y ago

I got the "you're a bit slow" once. Which was funny, because I was very focused and felt very productive at that time —more than ever before. Plus, some of my code allowed a business expert to contribute directly, which made us even faster. I have since realised it had nothing to do with my actual performance. It was a people thing.

Noumenon72 10y ago
Please elaborate on the people thing.
- loup-vaillant 10y ago
  During my job interview, I was told we were going to be equals. Like, explicitly. He was older, and came to the project earlier, so I still deferred to him. Nevertheless, I treated him like a peer. Turned out he wanted to be the boss —that was made official 2 months after my arrival. On my very first week, he started to make disparaging comments under the guise of joke (or were those real jokes?). Those soon occurred daily. Sometimes in front of the client, who (surprise!) eventually lost trust in me. If this was my only experience, I would have thought it was me. But I have since received enough external validation about my skills (people looking up to me, actual results…) to know better. For some reason, the guy could not stand me, so he got rid of me. Another small detail: he never smiled at me in the morning when we shook hands to say hello. He did smile at everyone else.

dunkelheit 10y ago

One general piece of advice that stuck with me after reading "Feeling Good: The New Mood Therapy" (a cognitive therapy book) is to refrain from thinking in inherent categories about myself. Thinking "I'm a slow developer" is just depressing and sad - there is nothing much you can do about your inherent flaw. By contrast, thinking "I've done this task slowly" puts you in a problem-solving mood. Something like "Wow, I've actually shipped, that's great! Now, it took me a bit more time than I've anticipated. Does it really matter? If it does, what can I do about it?" Also, a lot of this is just management trying to put pressure on the devs using methods more appropriate for a kindergarten. I vividly remember my former boss telling me "you are going to put down the team and have a bad conscience if you don't finish this feature on time" (an arbitrary deadline caused by a looming performance review). He was a good boss, but I would have more appreciated an honest "look, I'm trying to get you a raise so finishing this feature by this date is in our mutual interest" without any kind of moralizing shit.

GoToRO 10y ago

Most people cut corners. They deliver crap, fast. But when you add the time needed to debug that crap, to refactor it, was it really fast? Of course managers don't track time over the whole life of a feature... - So it says in your CV that you are quick at math. - Yes. Yes I am. - How much is 23 times 14. - 7! - That's not even close! - No. But it was quick!

pmarreck 10y ago

I was challenged by my bosses at my last job because they were concerned about overall team productivity (including mine... mainly because I spent some additional time refactoring and creating better testing tools, because those were necessary and coworkers reported them as cool and labor-saving) and they put us in a "bataan death march" mode without a definite ending (...) and I pushed back and said this is bullshit because what these metrics I took say is that we need to be paying down some tech debt, stat. I ended up leaving. Sometimes, the job is too good for you, and sometimes you are too good for the job.

nope_42 10y ago

Having read some of the comments in here I'm surprised to see that no one has mentioned how the co-workers reporting their time are lying and this developer isn't. If you worked on a feature for an hour and stared off into space for another hour you report that the feature took two hours. If you took 30 minutes to write an email you certainly don't report that; you move time around to make it look better. This behavior is totally normal in this industry and if you get put in a situation like that you have to do the same. No one can concentrate for 40 hours every week on development without getting burned out. The reality is most people are probably lucky to get 20 hours of productive work done a week.

Sammi 10y ago
I do some of my best programming while I'm staring out the window or getting coffee or sitting on the toilet.
- tdy721 10y ago
  Me too, but it still feels cheating when I bill for that time.

phkahler 10y ago

>> Bathroom breaks were consider unproductive, talking to co-workers was considered unproductive, and doing any kind of research was pointless unless we could bill a customer. That is simply bullshit. Don't take anything they say seriously except the broadest interpretation of what the project is. It sounds like the writer has something north of basic competence. In that case, just do your job mostly your way and don't give a fuck what the others think. If THEY don't think you're worth your price they won't keep paying you. It's really as simple as that. And if you do find yourself out on the street then you can sit back and try to decide how to partition the failure between yourself and the company. If there's any blame you can clearly put on yourself then work on that. Otherwise just assume it's them and move on. The longer you work in the field, the more you can assume you don't suck regardless of what people appear to think. In other words, actions speak louder than words or even company policy. If they're keeping you it's because you're valuable regardless of what they say.

edblarney 10y ago

"I mean, how could someone spend several hours trying to debug a table that looked one way on Firefox and one way on Chrome?" Because HTML and it's various implementations/versions are a Byzantine mess. 'Web development' is not so much development ... it's about knowing a myriad of little, innocuous details regarding various platform, api quirks, toolchain bits etc.. The 'development' part of web-dev is usually quite straight forward - you're not doing complex AI etc.. And fyi - development is 90% struggling through things you don't understand, bugs, hiccups etc.. A good chunk of the code you write like English. It's all about working through the pain points, making 'aha' realizations about how you structured something, or about some crazy API quirk. That's the job.

j45 10y ago

In a way, most people should be doing bad work today.. looking 5 years back.

ilaksh 10y ago

Seems like people are misinterpreting what he is saying. He is NOT saying he really thinks he is slow. I think this is a polite and less direct way of saying that constant pressure to increase 'productivity' is counter-productive in terms of outcomes and harmful to employees psychologically.

orbitingpluto 10y ago

I've told this story before, so here is the short version. I replaced $girl in a sysadmin/programming role that would get used by other employees. According to my supervisor, she was always far more productive than me. He'd ask for an estimate of how long something would take and he'd always say, "That's too long. $girl could do it half the time." Well, because it was my first tech job company, I sort of had impostor syndrome because of him but also thought of a way to test it out. One job we often had would get programmed from scratch several times a year and take about 2 or 3 hours to do. I cludged it into a simple framework where I could just edit the XML after the other employees started to use it. So when he asked me how long it was going to take before people could start using it I said thirty seconds. "That's too long... $girl could do it 15..., wait, what?"

effie 10y ago
Wow, that had to crack you up laughing:)

AnneDev 10y ago

As the OP of the article, can someone tell me what I did wrong? https://news.ycombinator.com/item?id=13281186 https://news.ycombinator.com/item?id=13281186