

Things Great Engineers (Almost) Never Say - xivSolutions
http://jobtipsforgeeks.com/2012/10/08/things-great-engineers-almost-never-say/

======
mgkimsal
"“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.

~~~
sophacles
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.

~~~
mgkimsal
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.

------
jrajav
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-
almost-never-say/)

~~~
moondowner
DZone articles are always linked to the original at the end of the page.

~~~
jrajav
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>

~~~
xivSolutions
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
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.

------
recursive
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
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.

~~~
jib
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
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.

------
saucetenuto
> “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
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.

------
debacle
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
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
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.

~~~
henrik_w
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
"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.

------
larryfreeman
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
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.

------
stephengillie
_“There is no solution”_

Even Scotty can't rewrite the laws of physics...

~~~
xivSolutions
Yes, he can! :-)

