Things Great Engineers (Almost) Never Say(jobtipsforgeeks.com)
jobtipsforgeeks.com
Things Great Engineers (Almost) Never Say
http://jobtipsforgeeks.com/2012/10/08/things-great-engineers-almost-never-say/
8 comments
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.
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 thought I touched on that. If a decision was made aware of the options, and a suboptimal choice was found because of specific constraints (budget, technical, whatever), document that and move on. You're doing the best you can with the project constraints. Not being aware (or even doing the research) and ending up with suboptimal code when it wasn't necessary is the problem.
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.
Excellent point.
Excellent point.
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.
Please link directly to the original next time.
http://jobtipsforgeeks.com/2012/10/08/things-great-engineers...
http://jobtipsforgeeks.com/2012/10/08/things-great-engineers...
DZone articles are always linked to the original at the end of the page.
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
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
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 . . .
My bad, but please know I understood the guideline, just not the page I was linking to . . .
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.
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.
Thanks - I was trying to find that. DZone apparently doesn't want to make it easy to find the original.
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.
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."
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.
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.
"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.
This exactly.
Maybe a better way to say it is "There's no solution which I can implement in 5 minutes" or whatever time scale is suitable.
Maybe a better way to say it is "There's no solution which I can implement in 5 minutes" or whatever time scale is suitable.
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.
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.
> “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:
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"
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?"
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.
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.
> "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.
Your mental gymnastics are ridiculous. Just evaluate that statement as a normal English sentence.
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.
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.
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.
That's the fun part. Typing is an exercise best left for Mavis Beacon.
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.
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.
True enough!
Author here. I probably could have written 'I hate solving problems using technology' instead of 'I hate programming'. The point, as you noted, was that the challenge of solving problems with code never gets old. Rewriting repetitive code or just the simple task of typing certainly are not what great engineers enjoy.
'I hate solving problems using technology' is the opposite of an engineer.
> 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".
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".
[deleted]
I for one love programming (still, after 20 years in the profession). Some of the reasons I love it: http://henrikwarne.com/2012/06/02/why-i-love-coding/
"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’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.
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.
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.
* 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.
“There is no solution”
Even Scotty can't rewrite the laws of physics...
Even Scotty can't rewrite the laws of physics...
Yes, he can! :-)
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.