5 ms·

Things Great Engineers (Almost) Never Say

15 points by xivSolutions 14y ago

jrajav 14y ago
Please link directly to the original next time. http://jobtipsforgeeks.com/2012/10/08/things-great-engineers-almost-never-say/ http://jobtipsforgeeks.com/2012/10/08/things-great-engineers...
- moondowner 14y ago
  DZone articles are always linked to the original at the end of the page.
  - xivSolutions 14y ago
    Thanks - I was trying to find that. DZone apparently doesn't want to make it easy to find the original.
    - jrajav 14y ago
      For what it's worth, I would recommend a quoted google search of a sentence somewhere in the article content for any aggregator-esque blogs.
  - jrajav 14y ago
    From the guidelines [1]: Please submit the original source. If a blog post reports on something they found on another site, submit the latter. [1]: http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
    - xivSolutions 14y ago
      In truth, I looked around the DZone article (which is how it is referred to on the DZone site). When I couldn't find a readily visible link to the original, I assumed is was content written on the DZone site, much like articles on CodeProject (as opposed to technical blog links on CodeProject, where there is a clearly identified link to the source). My bad, but please know I understood the guideline, just not the page I was linking to . . .
      - jpro 14y ago
        I'm glad you linked to it. Honestly I can't take the time to find all the curated blogs that DZone brings into the single feeds on Javalobby and Web Builder Zones.
      - moondowner 14y ago
        Just search for 'source' next time. Note that DZone also has original articles and in those cases you won't find linking to the source at the end of them.
recursive 14y ago
I disagree with this one. “There is no solution” I can't imagine a great engineer saying. "I've reduced this to the halting problem. Others have said that there is no solution, but I think they lack vision."
- dasil003 14y ago
  When managers ask for something they are typically not asking a math question. They are asking for a solution to a real world problem. There are always approximations of a solution even if a perfect one doesn't exist.
  - mgkimsal 14y ago
    Sometimes the 'solution' isn't technical, but process/training changes, or other human-level modifications, not code or tech. People don't always like to hear that, but understanding that may be an option on the table, and what the implications are, can help decision makers make better decisions.
    - dasil003 14y ago
      Good point. I won't say awareness of such solutions is a sign of a good programmer (though there's probably at least some correlation), but it's definitely the sign of a good consultant.
  - jib 14y ago
    Yeah I think this one is just semantics/being at least a bit politically aware. "There is no solution" is for most shorthand for "I can give you 20 solutions, but I don't think any of them are good enough to be effective for this case. Would you like to hear the 3 best ones I've thought of?" It's a bad kind of shorthand to use. Stating that "these are the best solutions I know of right now, and I've exhausted my current ideas" is better than saying there's no solution - it avoids it seeming like you're just not interested. Everything has a best solution after all, even if that solution may not be good enough.
stephengillie 14y ago
“There is no solution” Even Scotty can't rewrite the laws of physics...
- xivSolutions 14y ago
  Yes, he can! :-)
debacle 14y ago
This is a bunch of bollocks. I take issue with almost every one of these, but this one in particular: > "I hate programming" It's true! And there's nothing to really be said about it. If I liked programming I wouldn't write functions or create reusable pieces of code. I believe every good engineer loathes programming, and wants to do of little of it as necessary to get the job done.
- xivSolutions 14y ago
  That doesn't mean a hiring manager wants to hear that, which is at least one of the points of the article. I do believe he refers to that idea, at least indirectly. Also note, just because one loves programming does not mean one enjoys repetitively writing the same code, over and over again. Note to mention the fact that duplicating code within a project (instead of creating "reusable pieces of code") creates design problems and maintainability issues. I believe most good engineers ejoy employing an elegant solution, and focusing on the problem to be solved. They don;t enjoy solving the same old problem ("Gotta write another data access layer now, before I can build the fun part of the app . . ." as an example) over and over again by writing what amounts to boilerplate code.
  - debacle 14y ago
    Most good engineers will have the solution designed before they start programming, whether on paper or in their head. That's the fun part. Typing is an exercise best left for Mavis Beacon.
    - xivSolutions 14y ago
      True enough!
    - henrik_w 14y ago
      My experience is that when the problem is complex, the planned solution might still work, but there are often aspects I didn't think about that requires adapting the solution. So it's not just a matter of typing it up. I think programming to a large extent is a learning experience, and you adapt the solution as you learn more trying to solve the problem. For me at least it is a lot more iterative than simply typing the solution.
toolslive 14y ago
"There is no solution". Well, sometimes you can prove it too. "I’ve learned all I want/will ever need to know about X". Often you don't need to know everything about X before you decide you don't want to be anywhere near X. "I hate programming" (in X). Lot's of times this stems from the frustration with the programming language/environment mismatch between X and the problem at hand.
mgkimsal 14y ago
"“I will need ______ (tool/condition) to complete this task” – The masters of development will have the ability to improvise and adjust on the fly to arrive at a solution in non-ideal conditions. When you hear of engineers being compared to MacGyver they are speaking of this very rare skill. Greats will figure out a way based on minimal resources and will be aware of alternatives to their first choice of tool." I see the opposite as a problem - not being aware of standard solutions for tools, and reinventing the wheel yet again without even bothering to go look for something that might exist already. Praising this 'macgyver' skill reinforces in people's minds that it's perfectly fine (perhaps desirable) to "roll your own" all the time. The extra couple hours or days you spend up front understanding tools that tens of thousands of other people already know will pay off down the line when you hit configuration, scaling, performance, security or other problems vs your home grown 'solution'. This has continually been something I've run in to the past few years, and it reminds me of my own 'roll your own' justifications from 10-15 years ago. The only defenses I have are back then there was far less available open source tools (or even closed source) for many of the problem domains I hit back in the mid 90s. Today that's far less of an issue in most situations, and I'm far more sensitive to the maintenance burden imposed by a 'roll your own' mindset (because I've had to maintain my own code from 10 years ago!). It's one thing if the primary options are off the table due to budgetary issues (hit me recently as well), but in most cases I find it's people not being aware (and not researching) to see if industry standard options exist.
- fecak 14y ago
  Author here. That is a very interesting point. My point was that great engineers will know which tool is optimal yet will be able to identify a new solution. I could certainly see situations where perhaps an ego causes someone to always think he/she can build a tool better than the ones that already exist and function fine. It's over-engineering. Excellent point.
  - mgkimsal 14y ago
    Sometimes ego, sometimes just lack of experience. In my case, initially it was primarily lack of experience, then I went through the ego stage, and now I do what I can to use pre-existing stuff, and I've done this long enough where I know there's likely options I need to research/explore before making a decision.
saucetenuto 14y ago
> “I will need ______ (tool/condition) to complete this task” Yeah, this one is nonsense. I think I see what the author meant, though. Consider this conversation: Engineer: “I will need ______ (tool/condition) to complete this task” Manager: "You can't have it" IME, great engineers distinguish themselves by their reply: Bad Engineer: "Then I guess we can't do it" Good Engineer: "Hmm...what if we had these other things?" Great Engineer: "Hmm...what if we solved this other problem?" There's some overlap, of course, but my experience is that good engineers find creative ways to deliver the feature, while great engineers find creative ways to solve the problem, if you see what I mean.
- fecak 14y ago
  Author here, points well taken, and your illustration is pretty close to my intent. I'd say regarding a specific tool, a great engineer could probably solve the problem at hand effectively without having to rely on any one specific tool. If you work for a company that has standardized technology roadmaps where certain tools are forbidden (think regulated industries, some gov't), a great engineer will know of or find another tool to use within those guidelines. Regarding a specific condition, I could see where there are times when one may need to solve another problem.
larryfreeman 14y ago
In my experience, passion is key. I consider great engineers to be engineers who get things done and their solution stands up to review over time. These types of answers are usually tell-tale signs of engineers that are harder to work. But from my 20+ years experience, they are not necessarily a sign of engineers lacking passion. I've found great engineers who said the following: * I have no idea how it works (he was talking about Windows and explaining why he preferred Linux) * I've learned all I've ever want to know about... (he was talking about Visual Basic) * There is no solution... (reaching a consensus every time) * I'm an expert in Ruby (he was) * I don't understand the business... (I'm just trying to make great software) edit: I removed the Jeff Bezos line. This came from a keynote he made at Stanford. He was really saying that he doesn't pay much attention to his competitors.
- fecak 14y ago
  Author here, and some good points raised. A couple thoughts: * If an engineer explained why he preferred Linux to windows, he wouldn't be thorough if he didn't at least have some understanding as to why Linux was a better solution. I would assume some knowledge of the workings of Windows would be necessary to contrast the two systems. One could simply point to a performance metric perhaps, but a great engineer should dig deeper to make an effective argument. * There are certainly some people who will claim to be experts in a particular area. True experts, in most cases, won't have to say it. * Trying to make great software to solve business problems should require some understanding of the business problems being solved, no? I don't think you can really solve a problem without knowing what the problem is. Of course, my comments here are assuming that you are building software to solve a problem for a business - the 'business' could be substituted with 'the problem being solved', and perhaps that would make more sense for my statement if you are taking the word business literally.

15 points by xivSolutions 14y ago

Please link directly to the original next time. http://jobtipsforgeeks.com/2012/10/08/things-great-engineers-almost-never-say/ http://jobtipsforgeeks.com/2012/10/08/things-great-engineers...

moondowner 14y ago
DZone articles are always linked to the original at the end of the page.
- xivSolutions 14y ago
  Thanks - I was trying to find that. DZone apparently doesn't want to make it easy to find the original.
  - jrajav 14y ago
    For what it's worth, I would recommend a quoted google search of a sentence somewhere in the article content for any aggregator-esque blogs.
- jrajav 14y ago
  From the guidelines [1]: Please submit the original source. If a blog post reports on something they found on another site, submit the latter. [1]: http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
  - xivSolutions 14y ago
    In truth, I looked around the DZone article (which is how it is referred to on the DZone site). When I couldn't find a readily visible link to the original, I assumed is was content written on the DZone site, much like articles on CodeProject (as opposed to technical blog links on CodeProject, where there is a clearly identified link to the source). My bad, but please know I understood the guideline, just not the page I was linking to . . .
    - jpro 14y ago
      I'm glad you linked to it. Honestly I can't take the time to find all the curated blogs that DZone brings into the single feeds on Javalobby and Web Builder Zones.
    - moondowner 14y ago
      Just search for 'source' next time. Note that DZone also has original articles and in those cases you won't find linking to the source at the end of them.

recursive 14y ago

I disagree with this one. “There is no solution” I can't imagine a great engineer saying. "I've reduced this to the halting problem. Others have said that there is no solution, but I think they lack vision."

dasil003 14y ago
When managers ask for something they are typically not asking a math question. They are asking for a solution to a real world problem. There are always approximations of a solution even if a perfect one doesn't exist.
- mgkimsal 14y ago
  Sometimes the 'solution' isn't technical, but process/training changes, or other human-level modifications, not code or tech. People don't always like to hear that, but understanding that may be an option on the table, and what the implications are, can help decision makers make better decisions.
  - dasil003 14y ago
    Good point. I won't say awareness of such solutions is a sign of a good programmer (though there's probably at least some correlation), but it's definitely the sign of a good consultant.
- jib 14y ago
  Yeah I think this one is just semantics/being at least a bit politically aware. "There is no solution" is for most shorthand for "I can give you 20 solutions, but I don't think any of them are good enough to be effective for this case. Would you like to hear the 3 best ones I've thought of?" It's a bad kind of shorthand to use. Stating that "these are the best solutions I know of right now, and I've exhausted my current ideas" is better than saying there's no solution - it avoids it seeming like you're just not interested. Everything has a best solution after all, even if that solution may not be good enough.

stephengillie 14y ago

“There is no solution” Even Scotty can't rewrite the laws of physics...

xivSolutions 14y ago
Yes, he can! :-)

debacle 14y ago

This is a bunch of bollocks. I take issue with almost every one of these, but this one in particular: > "I hate programming" It's true! And there's nothing to really be said about it. If I liked programming I wouldn't write functions or create reusable pieces of code. I believe every good engineer loathes programming, and wants to do of little of it as necessary to get the job done.

xivSolutions 14y ago
That doesn't mean a hiring manager wants to hear that, which is at least one of the points of the article. I do believe he refers to that idea, at least indirectly. Also note, just because one loves programming does not mean one enjoys repetitively writing the same code, over and over again. Note to mention the fact that duplicating code within a project (instead of creating "reusable pieces of code") creates design problems and maintainability issues. I believe most good engineers ejoy employing an elegant solution, and focusing on the problem to be solved. They don;t enjoy solving the same old problem ("Gotta write another data access layer now, before I can build the fun part of the app . . ." as an example) over and over again by writing what amounts to boilerplate code.
- debacle 14y ago
  Most good engineers will have the solution designed before they start programming, whether on paper or in their head. That's the fun part. Typing is an exercise best left for Mavis Beacon.
  - xivSolutions 14y ago
    True enough!
  - henrik_w 14y ago
    My experience is that when the problem is complex, the planned solution might still work, but there are often aspects I didn't think about that requires adapting the solution. So it's not just a matter of typing it up. I think programming to a large extent is a learning experience, and you adapt the solution as you learn more trying to solve the problem. For me at least it is a lot more iterative than simply typing the solution.

toolslive 14y ago

"There is no solution". Well, sometimes you can prove it too. "I’ve learned all I want/will ever need to know about X". Often you don't need to know everything about X before you decide you don't want to be anywhere near X. "I hate programming" (in X). Lot's of times this stems from the frustration with the programming language/environment mismatch between X and the problem at hand.

mgkimsal 14y ago

"“I will need ______ (tool/condition) to complete this task” – The masters of development will have the ability to improvise and adjust on the fly to arrive at a solution in non-ideal conditions. When you hear of engineers being compared to MacGyver they are speaking of this very rare skill. Greats will figure out a way based on minimal resources and will be aware of alternatives to their first choice of tool." I see the opposite as a problem - not being aware of standard solutions for tools, and reinventing the wheel yet again without even bothering to go look for something that might exist already. Praising this 'macgyver' skill reinforces in people's minds that it's perfectly fine (perhaps desirable) to "roll your own" all the time. The extra couple hours or days you spend up front understanding tools that tens of thousands of other people already know will pay off down the line when you hit configuration, scaling, performance, security or other problems vs your home grown 'solution'. This has continually been something I've run in to the past few years, and it reminds me of my own 'roll your own' justifications from 10-15 years ago. The only defenses I have are back then there was far less available open source tools (or even closed source) for many of the problem domains I hit back in the mid 90s. Today that's far less of an issue in most situations, and I'm far more sensitive to the maintenance burden imposed by a 'roll your own' mindset (because I've had to maintain my own code from 10 years ago!). It's one thing if the primary options are off the table due to budgetary issues (hit me recently as well), but in most cases I find it's people not being aware (and not researching) to see if industry standard options exist.

fecak 14y ago
Author here. That is a very interesting point. My point was that great engineers will know which tool is optimal yet will be able to identify a new solution. I could certainly see situations where perhaps an ego causes someone to always think he/she can build a tool better than the ones that already exist and function fine. It's over-engineering. Excellent point.
- mgkimsal 14y ago
  Sometimes ego, sometimes just lack of experience. In my case, initially it was primarily lack of experience, then I went through the ego stage, and now I do what I can to use pre-existing stuff, and I've done this long enough where I know there's likely options I need to research/explore before making a decision.

saucetenuto 14y ago

> “I will need ______ (tool/condition) to complete this task” Yeah, this one is nonsense. I think I see what the author meant, though. Consider this conversation: Engineer: “I will need ______ (tool/condition) to complete this task” Manager: "You can't have it" IME, great engineers distinguish themselves by their reply: Bad Engineer: "Then I guess we can't do it" Good Engineer: "Hmm...what if we had these other things?" Great Engineer: "Hmm...what if we solved this other problem?" There's some overlap, of course, but my experience is that good engineers find creative ways to deliver the feature, while great engineers find creative ways to solve the problem, if you see what I mean.

fecak 14y ago
Author here, points well taken, and your illustration is pretty close to my intent. I'd say regarding a specific tool, a great engineer could probably solve the problem at hand effectively without having to rely on any one specific tool. If you work for a company that has standardized technology roadmaps where certain tools are forbidden (think regulated industries, some gov't), a great engineer will know of or find another tool to use within those guidelines. Regarding a specific condition, I could see where there are times when one may need to solve another problem.

larryfreeman 14y ago

In my experience, passion is key. I consider great engineers to be engineers who get things done and their solution stands up to review over time. These types of answers are usually tell-tale signs of engineers that are harder to work. But from my 20+ years experience, they are not necessarily a sign of engineers lacking passion. I've found great engineers who said the following: * I have no idea how it works (he was talking about Windows and explaining why he preferred Linux) * I've learned all I've ever want to know about... (he was talking about Visual Basic) * There is no solution... (reaching a consensus every time) * I'm an expert in Ruby (he was) * I don't understand the business... (I'm just trying to make great software) edit: I removed the Jeff Bezos line. This came from a keynote he made at Stanford. He was really saying that he doesn't pay much attention to his competitors.

fecak 14y ago
Author here, and some good points raised. A couple thoughts: * If an engineer explained why he preferred Linux to windows, he wouldn't be thorough if he didn't at least have some understanding as to why Linux was a better solution. I would assume some knowledge of the workings of Windows would be necessary to contrast the two systems. One could simply point to a performance metric perhaps, but a great engineer should dig deeper to make an effective argument. * There are certainly some people who will claim to be experts in a particular area. True experts, in most cases, won't have to say it. * Trying to make great software to solve business problems should require some understanding of the business problems being solved, no? I don't think you can really solve a problem without knowing what the problem is. Of course, my comments here are assuming that you are building software to solve a problem for a business - the 'business' could be substituted with 'the problem being solved', and perhaps that would make more sense for my statement if you are taking the word business literally.