6 ms·

I agree absolutely with him and I disagree with raganwald. Why is this? Because there are only so many rockstars you can have in one joint. There are only so m

I agree absolutely with him and I disagree with raganwald. Why is this? Because there are only so many rockstars you can have in one joint. There are only so many people who live and breath code you can have in one room before trouble starts brewing. Every team needs a crop of solid, dependable and slow developers that do the boring tasks. The guy who does not mind going over all the functions and commenting them. The guy who is satisfied to port a C script to Mac OS X, even though it is mindless bug testing. And those type of guys don't code at home. If you will never hire such people, then who will do the boring tasks? Your highly intelligent and highly paid coders? You recruit them to put them for 3 months working on some inane and boring database program? Intellectual diversity is a neccessity in any shop that makes its living from brainwork.

weavejester 17y ago
It seems to me that "boring" often means "potentially automatable".
- maxklein 17y ago
  How do you automate the writing of a script that copies data across 5 servers? Or an Excel macro for some business thing? Or porting an app to another platform You need developers for many things that cannot be automated.
  - daleharvey 17y ago
    or you just need smarter programs I mean, I get the point, but making mundane tasks easy to do or removing the need to do them at all is kinda what we do as programmers.
    - thenduks 17y ago
      It's what we do as passionate programmers who enjoy doing it. To 'the rest' it's just a job that ends every day at 5pm. In other words, to the 'career programmer' automating something like the examples given is simply lowering your job security.
      - coliveira 17y ago
        I always laugh at people who talk about the job security in writing bad code. The most secure job is for the one person that knows what he/she is doing, because they will find another one easily.
        deleted 17y ago
        [deleted]
  - timwiseman 17y ago
    The answer is often by answering a higher level problem. For instance, writing a script that copies data across 5 servers with no major issues in the way is boring, but writing a script that synchronizing data across an arbitrary number of servers can be hard, interesting, and more valuable. When it is done, just hand it to the admin to apply to those particular 5 servers. Simple macros are often done by business power users instead of developers, but if it is something complicated then it is complicated and interesting. As for porting an app, there is some work on automating that depending on what the source and destination platforms are. The proper choice of language can minimize the work in the first place, and then you can build (or buy) tools to help automate at least large portions of the automation. Also, keep in mind there is a difference between knowingly hiring "bad programmers" and hiring "junior programmers." Bad programmers as the term seems to be used in this thread have no intention of improving, are good enough to get the job done eventually, but make no outside efforts. "Junior programmers" are often willing to do the boring stuff when they get started, but then they get better. You may have to deal with the fact they will want either promotion or to change companies in the near future, but in the meantime you get to benefit from the fact that they are constantly improving and using their own resources to do that.
  - rsheridan6 17y ago
    Strong AI?
- ramchip 17y ago
  I maintain a C++ app. Making the GUI, implementing the button callbacks, and writing the settings save/restore logic is all easy and boring compared to the signal and image processing core. But I can't possibly automate this, and I would be very happy to let a decent but less passionate or experienced, day-job coder do the GUI code while I take care of the more challenging parts. Even if I had to take more time teaching him than I would be doing it myself, I'd do it! More enjoyable and useful in the long-term.
  - weavejester 17y ago
    I'm not sure I'd consider GUI design as easy and boring, just requiring a different set of skills to most programming work. Designing a good UI can be extremely difficult. I also don't understand why you can't automate things like saving and restoring settings. It seems to me that there are plenty of things interesting things you can do in a UI framework.
    - ramchip 17y ago
      > I also don't understand why you can't automate things like saving and restoring settings. Because of C++ :) More seriously, it's the actual design of the options screen. Different variables are hooked to different controls, and I have to make sure that eg. when a frequency (in Hz) is loaded from the registry, it is converted to GHz and the control is set to the appropriate value. Little things like this. I use Qt which is very good and abstracts the actual registry/config file access, but it cannot guess things for me. GUI design isn't always easy and boring, but I work on physics data acquisition apps that have 2 or 3 users in total, so literally nobody cares about the UI as long as the experiment data is fine. It could take 10 minutes to figure out the controls and the user would still be happy. Physicists are used to making and using GUIs that would make you weep! In my case the GUI is a very easy to solve problem compared to the rest of the code. Of course things would be different if I made an app with millions of users, a web app, etc.
st3fan 17y ago
"""Every team needs a crop of solid, dependable and slow developers that do the boring tasks.""" Well put. And this is exactly the role for which I would hire Ted if his interview gave me the same impression of him as that blog entry.
- gscott 17y ago
  Plus dependable programmers are fired last.
  - mahmud 17y ago
    No they are not! My colleague is Mr "Can't Do". Where the rest of us see opportunity and "cool" he sees problems. He has put his job on the line for us many times over telling the CEO to curb his dreams and enthusiasm and ship something that works first. Incidentally, he has been .NET/PHP corporate programming guy and never ventured outside reporting and billing software. Today he is our rockstar. Every time the rest of us are getting ahead of ourselves we turn to him for feedback and if he is even marginally un-pissed-off by our ideas, we know we're doing the right thing. If it wasn't for him, nothing would have shipped and none of us would still be on the project, since 3 of us are dyed-in-the-wool technophiles (hello? 2 Lispers and a game developer?)
    - gscott 17y ago
      I have a friend who is a very good developer, he happens to be reliable, dependable, and can get things done. He comes in and leaves at the same time each day (dependable). Myself, I developed the intial product and the next generation product, but I would work all night, weekends, sometimes several days straight. I wasn't coming in and leaving at the same time of the day. In the end dependable was better then myself, he is buying two houses, going on nice vacations, while I was left out in the cold when things were temporarily difficult. I would prefer to be in a different situation. If I was just dependable it would be better then imaginative. I would prefer to crank things out rather then go so hot and cold.
    - maxklein 17y ago
zackattack 17y ago
This is really insightful. Thanks.
gorbachev 17y ago
So you think not doing coding at home puts you in the "let's assign all the boring tasks to this guy" career development track? Seriously?
aminuit 17y ago
I can't believe people are agreeing with you. I'm not even sure you've ever written software professionally. C script? C is compiled. Nobody says "C script". One developer commenting other developers code? That's ridiculous. You're either a highly effective troll or totally clueless.
- randallsquared 17y ago
  One developer commenting other developers code? That's ridiculous. It's not. When you write something, it's often not at all obvious what to write as a comment, precisely because the purpose and detailed reasoning is obvious. When someone else comes along and doesn't immediately understand the code, they're in a much better position to comment it.
gruseom 17y ago
Your assumptions are wrong. Egotism makes a programmer weaker, not stronger. Those who consider themselves rockstars are, in my observation, never the best. And they're a pain to work with because they get defensive about ideas. The great programmers I've known have also been the most fun to work with. It's a team sport.
raganwald 17y ago
The rockstar thing is a strawman wrt to me. I never said I wanted to hire rockstars. What I said was, I only interview people I know or who know me through my physical and virtual networks, and doing so has by and large given me a decent number of hires. p.s. And that is an entirely debatable strategy regardless of whether such people are or are not rockstars :-)
crucini 17y ago
I'm ambivalent about this concept. I agree that everywhere I've worked, there's been a residue of boring yet necessary stuff like your describing. Sometimes the residue could be reduced by automation; not always. However I'm very concerned about the potential of these 'slow' developers injecting bad code into the codebase. By bad, I mean redundant. The 'slow' developer will create code that later gets maintained by the 'quick' developer - who is soon disgrunted and slow. Unless he just rewrites it from scratch. If you really have a steady stream of 'stuff' to feed the 'slow' developer, great. Otherwise he will work through his queue and end up smearing cruft around. I don't know the answer, but I'd rather have a very bright, very inexperienced developer for that role than a 'slow' one.

weavejester 17y ago

It seems to me that "boring" often means "potentially automatable".

maxklein 17y ago
How do you automate the writing of a script that copies data across 5 servers? Or an Excel macro for some business thing? Or porting an app to another platform You need developers for many things that cannot be automated.
- daleharvey 17y ago
  or you just need smarter programs I mean, I get the point, but making mundane tasks easy to do or removing the need to do them at all is kinda what we do as programmers.
  - thenduks 17y ago
    It's what we do as passionate programmers who enjoy doing it. To 'the rest' it's just a job that ends every day at 5pm. In other words, to the 'career programmer' automating something like the examples given is simply lowering your job security.
    - coliveira 17y ago
      I always laugh at people who talk about the job security in writing bad code. The most secure job is for the one person that knows what he/she is doing, because they will find another one easily.
      - deleted 17y ago
        [deleted]
- timwiseman 17y ago
  The answer is often by answering a higher level problem. For instance, writing a script that copies data across 5 servers with no major issues in the way is boring, but writing a script that synchronizing data across an arbitrary number of servers can be hard, interesting, and more valuable. When it is done, just hand it to the admin to apply to those particular 5 servers. Simple macros are often done by business power users instead of developers, but if it is something complicated then it is complicated and interesting. As for porting an app, there is some work on automating that depending on what the source and destination platforms are. The proper choice of language can minimize the work in the first place, and then you can build (or buy) tools to help automate at least large portions of the automation. Also, keep in mind there is a difference between knowingly hiring "bad programmers" and hiring "junior programmers." Bad programmers as the term seems to be used in this thread have no intention of improving, are good enough to get the job done eventually, but make no outside efforts. "Junior programmers" are often willing to do the boring stuff when they get started, but then they get better. You may have to deal with the fact they will want either promotion or to change companies in the near future, but in the meantime you get to benefit from the fact that they are constantly improving and using their own resources to do that.
- rsheridan6 17y ago
  Strong AI?
ramchip 17y ago
I maintain a C++ app. Making the GUI, implementing the button callbacks, and writing the settings save/restore logic is all easy and boring compared to the signal and image processing core. But I can't possibly automate this, and I would be very happy to let a decent but less passionate or experienced, day-job coder do the GUI code while I take care of the more challenging parts. Even if I had to take more time teaching him than I would be doing it myself, I'd do it! More enjoyable and useful in the long-term.
- weavejester 17y ago
  I'm not sure I'd consider GUI design as easy and boring, just requiring a different set of skills to most programming work. Designing a good UI can be extremely difficult. I also don't understand why you can't automate things like saving and restoring settings. It seems to me that there are plenty of things interesting things you can do in a UI framework.
  - ramchip 17y ago
    > I also don't understand why you can't automate things like saving and restoring settings. Because of C++ :) More seriously, it's the actual design of the options screen. Different variables are hooked to different controls, and I have to make sure that eg. when a frequency (in Hz) is loaded from the registry, it is converted to GHz and the control is set to the appropriate value. Little things like this. I use Qt which is very good and abstracts the actual registry/config file access, but it cannot guess things for me. GUI design isn't always easy and boring, but I work on physics data acquisition apps that have 2 or 3 users in total, so literally nobody cares about the UI as long as the experiment data is fine. It could take 10 minutes to figure out the controls and the user would still be happy. Physicists are used to making and using GUIs that would make you weep! In my case the GUI is a very easy to solve problem compared to the rest of the code. Of course things would be different if I made an app with millions of users, a web app, etc.

st3fan 17y ago

"""Every team needs a crop of solid, dependable and slow developers that do the boring tasks.""" Well put. And this is exactly the role for which I would hire Ted if his interview gave me the same impression of him as that blog entry.

gscott 17y ago
Plus dependable programmers are fired last.
- mahmud 17y ago
  No they are not! My colleague is Mr "Can't Do". Where the rest of us see opportunity and "cool" he sees problems. He has put his job on the line for us many times over telling the CEO to curb his dreams and enthusiasm and ship something that works first. Incidentally, he has been .NET/PHP corporate programming guy and never ventured outside reporting and billing software. Today he is our rockstar. Every time the rest of us are getting ahead of ourselves we turn to him for feedback and if he is even marginally un-pissed-off by our ideas, we know we're doing the right thing. If it wasn't for him, nothing would have shipped and none of us would still be on the project, since 3 of us are dyed-in-the-wool technophiles (hello? 2 Lispers and a game developer?)
  - gscott 17y ago
    I have a friend who is a very good developer, he happens to be reliable, dependable, and can get things done. He comes in and leaves at the same time each day (dependable). Myself, I developed the intial product and the next generation product, but I would work all night, weekends, sometimes several days straight. I wasn't coming in and leaving at the same time of the day. In the end dependable was better then myself, he is buying two houses, going on nice vacations, while I was left out in the cold when things were temporarily difficult. I would prefer to be in a different situation. If I was just dependable it would be better then imaginative. I would prefer to crank things out rather then go so hot and cold.
  - maxklein 17y ago

zackattack 17y ago

This is really insightful. Thanks.

gorbachev 17y ago

So you think not doing coding at home puts you in the "let's assign all the boring tasks to this guy" career development track? Seriously?

aminuit 17y ago

I can't believe people are agreeing with you. I'm not even sure you've ever written software professionally. C script? C is compiled. Nobody says "C script". One developer commenting other developers code? That's ridiculous. You're either a highly effective troll or totally clueless.

randallsquared 17y ago
One developer commenting other developers code? That's ridiculous. It's not. When you write something, it's often not at all obvious what to write as a comment, precisely because the purpose and detailed reasoning is obvious. When someone else comes along and doesn't immediately understand the code, they're in a much better position to comment it.

gruseom 17y ago

Your assumptions are wrong. Egotism makes a programmer weaker, not stronger. Those who consider themselves rockstars are, in my observation, never the best. And they're a pain to work with because they get defensive about ideas. The great programmers I've known have also been the most fun to work with. It's a team sport.

raganwald 17y ago

The rockstar thing is a strawman wrt to me. I never said I wanted to hire rockstars. What I said was, I only interview people I know or who know me through my physical and virtual networks, and doing so has by and large given me a decent number of hires. p.s. And that is an entirely debatable strategy regardless of whether such people are or are not rockstars :-)

crucini 17y ago

I'm ambivalent about this concept. I agree that everywhere I've worked, there's been a residue of boring yet necessary stuff like your describing. Sometimes the residue could be reduced by automation; not always. However I'm very concerned about the potential of these 'slow' developers injecting bad code into the codebase. By bad, I mean redundant. The 'slow' developer will create code that later gets maintained by the 'quick' developer - who is soon disgrunted and slow. Unless he just rewrites it from scratch. If you really have a steady stream of 'stuff' to feed the 'slow' developer, great. Otherwise he will work through his queue and end up smearing cruft around. I don't know the answer, but I'd rather have a very bright, very inexperienced developer for that role than a 'slow' one.