Please link directly to the original next time.
http://jobtipsforgeeks.com/2012/10/08/things-great-engineers...
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 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.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.
"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.
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.
“There is no solution”
Even Scotty can't rewrite the laws of physics...
"“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.