Live data from Hacker News

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

medium.com

41–50 of 130 posts

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

#41
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.

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

#42

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…

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 do…

Oh I wholeheartedly agree with the last sentence. The best way I found of dealing with that is finding a way of getting in earlier than anyone you care to impress. With some luck they may leave earlier than you so you follow suit. Always give the impression (at least) of being present.

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

#43

> 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…

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?

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

#44
post #29

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…

> 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?

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.

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

#45
post #43

> 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…

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?

Is self doubt ever about being bad at something?

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

#46

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 d…

> 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.

Great quote ! The best solution to impostor syndrom.

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

#47
post #29

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…

> 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?

>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

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

#48
post #45
post #43

Earlier quoted context omitted.

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?

Is self doubt ever about being bad at something?

Yes, unless you believe that a) nobody is ever bad at anything, or b) nobody bad at something ever notices.

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

#49

    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.

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

#50

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 devel…

SME = Subject Matter Expert (if google is to be believed).

Yes. Also defined in author's last paragraph.
Post reply on HN