"“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.
I think there is a difference between "I will need..." and "Ideally we should use...". In the former, there is an implication that the only solution is the tool stated, while in the later, there is an understanding that the solution is possible without the tool, albeit not the best.
My reading of that statement was not that good engineers won't use the right tool for the job, but rather will use the best they can, and deal with imperfections. Almost as a rephrasing of the old adage: "'Tis a poor carpenter that blames his tools".
There are often factors outside the control of the engineers that dictate certain things that can and cannot be used. Sometimes they are political and sometimes they are more technical. The ability to get things done in spite of externally imposed limitations is something that should be praised. Even something as simple as the choice of platform can be a cause of not using the ideal solution... say there are only X, Y and Z allowed languages - using the cool library for language W is off the table, even though it is highly regarded as the correct and best solution.
I agree. It also points out to me my biggest complaint with calling programmers "software engineers". A Professional Engineer (i.e. licensed, capital P and E) would never say, "Oh, you don't have an arc welder? No rivet gun? Well, I suppose we could hold that bridge together with solder and a few toggle bolts."
This seems like a topic where the often dubious "engineer" title as applied to programming is actually meaningful. Engineer has professional and business connotations that set a corresponding bar for rolling-your-own being a justifiable course of action. Contrast that with programming that is primarily motivated by creativity or curiosity. There, rolling-your-own can still be the right thing to do even if you're aware of a pre-existing thing that's likely better than what you will come up with.
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.
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."
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.
> “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.
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.
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.
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.
> If I liked programming I wouldn't write functions
That's just reductive sniping for the sake of it. The word programming obviously implies a more abstract process than "filling up text files by typing".
"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.
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.
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.
[+] [-] mgkimsal|13 years ago|reply
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.
[+] [-] sophacles|13 years ago|reply
My reading of that statement was not that good engineers won't use the right tool for the job, but rather will use the best they can, and deal with imperfections. Almost as a rephrasing of the old adage: "'Tis a poor carpenter that blames his tools".
There are often factors outside the control of the engineers that dictate certain things that can and cannot be used. Sometimes they are political and sometimes they are more technical. The ability to get things done in spite of externally imposed limitations is something that should be praised. Even something as simple as the choice of platform can be a cause of not using the ideal solution... say there are only X, Y and Z allowed languages - using the cool library for language W is off the table, even though it is highly regarded as the correct and best solution.
[+] [-] pflats|13 years ago|reply
[+] [-] frou_dh|13 years ago|reply
[+] [-] fecak|13 years ago|reply
Excellent point.
[+] [-] jrajav|13 years ago|reply
http://jobtipsforgeeks.com/2012/10/08/things-great-engineers...
[+] [-] moondowner|13 years ago|reply
[+] [-] recursive|13 years ago|reply
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|13 years ago|reply
[+] [-] saucetenuto|13 years ago|reply
Yeah, this one is nonsense. I think I see what the author meant, though. Consider this conversation:
IME, great engineers distinguish themselves by their reply: 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|13 years ago|reply
Regarding a specific condition, I could see where there are times when one may need to solve another problem.
[+] [-] debacle|13 years ago|reply
> "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.
[+] [-] blub|13 years ago|reply
[+] [-] xivSolutions|13 years ago|reply
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.
[+] [-] frou_dh|13 years ago|reply
That's just reductive sniping for the sake of it. The word programming obviously implies a more abstract process than "filling up text files by typing".
[+] [-] henrik_w|13 years ago|reply
[+] [-] toolslive|13 years ago|reply
"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.
[+] [-] larryfreeman|13 years ago|reply
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|13 years ago|reply
* 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.
[+] [-] stephengillie|13 years ago|reply
Even Scotty can't rewrite the laws of physics...
[+] [-] xivSolutions|13 years ago|reply