121–130 of 130 posts
Earlier quoted context omitted.
> 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. I haven't played a single game where this was true. Simply because both the healer and the damage dealer can do damage but only a healer can heal.
I guess it would depend on whether the healer can heal himself or only teammates.
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…
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 lo…
> Don't scold the fast guy for being sloppy, give him tasks that require speed and solve bugs with better QA and tests. What if we're in finance industry working on critical systems and a bug mean millions dollars lost? Should we hire "sloppy" at all? I think not.
For maintaining business critical systems? Obviously not.
But not everything in the finance industry requires that sort of stability and uptime. There are needs around prototyping new products and services for customers, for example. Not to mention ferreting out Excel spreadsheets being used in unconventional ways and creating intranet web-apps to better fill those unmet needs.
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 lo…
> 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. I haven't played a single game where this was true. Simply because both the healer and the damage dealer can do damage but only a healer can heal.
Put another way, two healers vs. one damage dealer are more likely to be evenly matched than the other way around.
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…
>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 de…
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.
Earlier quoted context omitted.
But, at the risk of pointing out the bleeding obvious to those who seem to be struggling with reading as well as basketball, it would then not be your job.
Okay, let's use another example. I waited tables in high school. I was very bad. I knew I was bad, but I worked hard to improve. Still, even after a few years of experience a random person who had never had a job before could walk in and get better tips than me. My boss wouldn't fire me because I showed up for shifts, but I was generally a very poor waiter. Eventually I got smart and stopped waiting tables, and the w…
You forgot to add "AND still be employed in that capacity."
Earlier quoted context omitted.
>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 de…
> 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 val…
Of course, realistically few devs are so critical to a project that they couldn't be replaced by another strong developer with a month or two to learn the code base, or at least a part of it. Obvious exceptions for deep domain expertise and the like, of course. But I've worked on way too many rescue projects to believe anyone is truly irreplaceable in the normal course of events.
Earlier quoted context omitted.
>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 de…
> 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 val…