3 ms·

If you are hired to write code, that's the contract; your job IS to write code. Just like a plumber's job isn't to solve problems in general, just the problems

by pekk 12y ago

If you are hired to write code, that's the contract; your job IS to write code. Just like a plumber's job isn't to solve problems in general, just the problems involving plumbing, and that's what makes him a plumber instead of something else. Otherwise, there is no reason why we would call them plumbers, why they would get specifically educated in plumbing, and bring a plumber's toolbox. You don't call the plumber when you want a sandwich or a car repair. A plumber who lets clients jerk him around by having him make them sandwiches or answer their phones doesn't know his business. If you are a plumber, please don't tell me that you offer solutions. Please tell me you are a plumber so I don't have to get confused about what it is you are actually offering.

mathgeek 12y ago
> If you are a plumber, please don't tell me that you offer solutions. Please tell me you are a plumber so I don't have to get confused about what it is you are actually offering. This is a classic case of what happened in the pest termination industry. You have two types of terminating companies: the solution-based (a.k.a. recurring revenue) companies, and the one-shot companies that you pay to come kill the pests in your house. There's room in the world for both, depending on your specific desires and needs when you see a roach in your bedroom.
cookingsource 12y ago
I really have never seen a contract stating “coder” or anything similar. It always have something else, referring to the domain of knowledge they expect from us. For me that’s the important thing, coding is just the tool. In my case I love working making games, so if the current way for that were screwing things together I would happily be called Games Screwdriver. I think we both agree in most of the terms. Maybe I should have expressed myself better in the post. I meant to say, solve problems in the domains we have knowledge about. I’ll update it in the post. Thanks for your feedback
mattnewton 12y ago
I don't think this analogy is useful. I think understanding the why is important. The plumber knows why you want running water, has seen many homes with water systems similar to yours, and almost certainly owns a home himself. But introducing software into someone else's business has no such guarantee of familiarity. There has to be a discovery process, where you choose between several ways to fulfill the need, with a much larger problem space than home water systems. In my experience, a large part of software is automating processes, and I can't imagine replacing a process properly without understanding why it is done in the first place. Business owners can understand a problem at a high enough level to hire people to solve it, but software engineers in that position have to understand a problem so well that they can describe it to machines who will take every step at face value, executing it unthinkingly. Encoding a bit of the why something is being done, even if it's just in manual tests of the software, has been crucial for that software to do the job properly in my (limited) experience. I'm not being jerked-around being told to make sandwiches. I'm being told, the water-operated sandwich making machine is too slow/doesnt work properly. I might just as easily recommend a sandwich catering service, or pick up a manual on building fancy electric sandwich makers, as repair/enhance the water pipes. Disclaimer: I'm a young software engineer who, perhaps naively thinks I will always be able to join interesting projects and learn new things while being treated like a partner instead of a technician. This has been my experience so far, but perhaps you reach a point where, having specialized, you churn out the same solution for company after company in a niche for efficiency reasons.

by pekk 12y ago

mathgeek 12y ago

> If you are a plumber, please don't tell me that you offer solutions. Please tell me you are a plumber so I don't have to get confused about what it is you are actually offering. This is a classic case of what happened in the pest termination industry. You have two types of terminating companies: the solution-based (a.k.a. recurring revenue) companies, and the one-shot companies that you pay to come kill the pests in your house. There's room in the world for both, depending on your specific desires and needs when you see a roach in your bedroom.

cookingsource 12y ago

I really have never seen a contract stating “coder” or anything similar. It always have something else, referring to the domain of knowledge they expect from us. For me that’s the important thing, coding is just the tool. In my case I love working making games, so if the current way for that were screwing things together I would happily be called Games Screwdriver. I think we both agree in most of the terms. Maybe I should have expressed myself better in the post. I meant to say, solve problems in the domains we have knowledge about. I’ll update it in the post. Thanks for your feedback

mattnewton 12y ago

I don't think this analogy is useful. I think understanding the why is important. The plumber knows why you want running water, has seen many homes with water systems similar to yours, and almost certainly owns a home himself. But introducing software into someone else's business has no such guarantee of familiarity. There has to be a discovery process, where you choose between several ways to fulfill the need, with a much larger problem space than home water systems. In my experience, a large part of software is automating processes, and I can't imagine replacing a process properly without understanding why it is done in the first place. Business owners can understand a problem at a high enough level to hire people to solve it, but software engineers in that position have to understand a problem so well that they can describe it to machines who will take every step at face value, executing it unthinkingly. Encoding a bit of the why something is being done, even if it's just in manual tests of the software, has been crucial for that software to do the job properly in my (limited) experience. I'm not being jerked-around being told to make sandwiches. I'm being told, the water-operated sandwich making machine is too slow/doesnt work properly. I might just as easily recommend a sandwich catering service, or pick up a manual on building fancy electric sandwich makers, as repair/enhance the water pipes. Disclaimer: I'm a young software engineer who, perhaps naively thinks I will always be able to join interesting projects and learn new things while being treated like a partner instead of a technician. This has been my experience so far, but perhaps you reach a point where, having specialized, you churn out the same solution for company after company in a niche for efficiency reasons.