
What makes a great software engineer? - shawndumas
http://www.nczonline.net/blog/2009/08/21/what-makes-a-great-software-engineer/
======
Maro
Discipline.

With all due respect to the author, it's not what's described in the article:

1\. Always do it the right way: Well, what's the right way?

2\. Be willing to suffer: You can suffer a lot and turn out absolute crap. In
fact, if you turn out absolute crap you most certainly _will_ suffer.

3\. Never stop learning: You can learn all the trendy new technologies and
still be mediocre in all of them. In fact it's common for fanyboys.

4\. Lend a helping hand: It's common for mediocre programmers to spread
disinformation on their blogs.

5\. Take your time: And you can be slow doing it!

As I said, in my opinion software engineering is about discipline. You can do
great stuff in any language, C/C++/Pascal/Java/Python/whatever, whether you
use SVN or Git, whether you're on a Mac/Windows or Linux, but you have to be
disciplined. You have to be patient enough not to start coding like a monkey
and do come research before. I've known engineers who will do _weeks_ of
research before writing a single line of code, driving everyone mad, but
proving themselves right afterwards. You have to be patient enough to think
about your code before you write it, follow best-practices and some
conventions when you write, constantly re-factor you old crap, write good
comments, write Makefiles, etc. You have to be disciplined enough to do
testing, have a test environment and a deploy workflow. Write proper
documentation (if required), write commit messages, and so on. Engineering is
not science, so you don't have to invent the wheel, it's also not art, so you
don't have to be super-creative, but you have to be smart enough to be
disciplined in the old-school IBM way.

~~~
hello_moto
My dad has no background in IT at all. He once was appointed to lead the
Operation division (everything including IT). He saw that the systems his bank
used was buggy and spent a few days figuring out how the systems worked (flow
of the systems, input, output, users, etc).

He found the problems eventually. His solution to the CEO? The IT team should
be discipline in almost every step they execute. Discipline in terms of
execution, discipline in terms of documentation, discipline in terms of
logging information, etc.

Agile, SCRUM, or whatever new methodologies out there (including CMMI)
directing engineers in the software industry specifically to be more
discipline. Feel free to talk bad/negatives about CMMI, but the intention is
to figure out what went wrong and how to not repeat the bad experience
(describe in each level).

In Agile, process is not equal bureaucracy. Process is equals discipline. -
Eric Ries

UNIX/Linux philosophies teaches software developer to be discipline.

Google has a set of coding/commit rules, rigid structures regarding their
source code (code review, etc) because they knew if things were not in certain
order, chaos rises.

~~~
jrockway
_In Agile, process is not equal bureaucracy. Process is equals discipline. -
Eric Ries_

This is false. Agile is total bureaucracy. From "no code without passing
tests" to "pay $1 if you're late to the standup meeting", Agile is about
everything but writing software that works.

When I think back to "Agile" jobs I had, I can remember our team spending
about 4 months writing 3 files worth of code that did basically nothing for
the application as a whole. We did have a lot of meetings and tests, though.

Conversely, when I think about code I've written on my own without any
structure or rules, I have over 100 completed projects/libraries in a few
years of hacking. And when I think about code I've written for non-Agile jobs,
the amount is the same -- lots of reliable, finished projects.

Agile is a way for the bad programmers to slow down the good programmers, so
everyone can feel better about themselves. Avoid.

 _UNIX/Linux philosophies teaches software developer to be discipline._

How? When I write a Windows application, I have a full-screen Emacs with my
code, a compile buffer for builds and tests, and a ghci (etc.) buffer. When I
write a UNIX application, well, it's exactly the same.

~~~
hello_moto
> "Pay $1 if you're late to the standup meeting"

If you're discipline enough with your time, you shouldn't worry about things
like this. Life is not perfect, there will always be small things that might
bother you but not other people. Take it easy, besides, like I said, if you're
punctuate, why does it bother you much? maybe it is meant for your co-workers
that have time-management issues.

> "No code without passing tests"

I've worked with smart people with big ego swinging their code like the best
thing since slice of bread. I've worked with smart people who think they can
solve everything by raw-talent. I've worked with smart people but not careful.
In every situation, forcing TDD help to store "order".

People out there seems to echo the same story. Now here's the thing, what
should I do? should I accept your story and have blind-faith on the new guys?
Thinking that they're smart and all that and no unit-test?

Should I trust someone that say "I designed my code to be unit-testable, but I
have no time to write unit-tests"?

How many allegedly "good developers" out there that my company can afford to
pay? Market also determines the price and right now the price of junior
developers are quite high.

And one more thing: I respect your skill for having over 100 projects over a
few years of hacking. That's great. There should be more people like you, and
less number of failed projects out there. What I'm trying to say is that the
statistics (Standish Group) isn't on your side.

TDD is a topic that would always caused a disagreement with a group of
programmers who have "success stories" without TDD, open source projects where
there are no deadline and have millions contributors (well, eventually the bug
will be fixed right... eventually... someday).

~~~
Silhouette
If you're advocating things like TDD or fixed daily meetings, you should
perhaps avoid using words like "statistics". They most certainly are not on
your side; indeed, there is very little evidence that these trendy Agile-based
processes provide any benefit whatsoever.

~~~
hello_moto
I'm not sold completely on TDD. Part of me think that TDD is a necessary evil.
Some organizations have the resources to hire many QAs that might help to
reduce the number of unit-tests. I'm not saying that is the most cost
effective way to go.

Also, if the programmers words can be trusted (that their code is unit-
testable, instead of highly-coupled, lots of dependency cycle, etc), writing
unit-test last would be alright as well.

~~~
Silhouette
FWIW, I think the most important thing here is not to confuse use of unit
tests with the adoption of TDD. The former does not imply the latter: you can
write unit tests after you write your code, or even before/during writing code
for that matter, without being test- _driven_ in your approach.

I have yet to see any credible study that showed a benefit for TDD _and_
controlled for the use of unit testing as part of a more traditional
development process. There is some evidence that, at least for some types of
project, TDD has been more successful by some metrics than a heavyweight,
waterfall process with no unit testing, but there are usually so many
uncontrolled variables involved that it's hard to read much of value into any
of those results.

------
grayrest
> I am saying that you should try to accomplish the task on your own first,
> and if you get stuck, then ask for help. Don’t simply ask for help every
> time without first trying to solve the problem yourself. Chances are, you’ll
> find that you could have figured it out on your own once you know the
> answer.

If you're a junior engineer and are working with and older engineer you
respect. I highly recommend you try to solve the problem, make a start at it,
and then ask your mentor what they think of your approach at lunch, on break,
or at the end of the day. This gives you most of the benefit of actually
implementing something while saving you most of the pain of having to maintain
your mistakes.

~~~
jrockway
Yes, this is a good idea. I think you can get 90% of the way there on your own
though, by asking yourself a few questions. Does it work? Am I sure it works?
Will I be able to replace this code with new code in a year without touching
anything else?

By the time you've answered "Am I sure it works?", the answer to the next
question is almost always yes. If you can test something enough to be sure it
works, it's probably modular enough for your application, too.

------
njharman
Communication is important enough to have had it's own section. Communicating
to future maintainers through code, comments, tests, and documentation.
Communicating designs, ideas, issues with team and leaders. Communicating
everything with designers, customers, testers, and stake holders.

A good engineers are good individually. Great engineers work with and elevate
the _team(s)_ they are part of. In military parlance they are force
multipliers.

------
matwood
Always do it the right way? What way is the right way? The right way from an
engineering standpoint or a business standpoint?

In my experience the right engineering way and right business way are often at
odds. My boss just says I'm 'developing under protest' in these situations. :)

------
j_baker
There's one thing that's missing from these kinds of posts. Usually, they
describe _a_ set of characteristics of great software engineers. However, you
have to be careful not to confuse that with _the_ set of characteristics of a
great programmer.

~~~
Silhouette
Your contrast between "software engineer" in one sentence and "programmer" in
the next is interesting. Did you mean to imply that there really is only one
set of characteristics that define a great _programmer_ , or were you assuming
that software engineers and programmers are the same thing? (I disagree in
either case, but I'm not sure how to parse your post to debate the point you
intended to make.)

~~~
j_baker
I'm using them interchangeably. :-)

~~~
Silhouette
In that case, let me suggest as an alternative that a common problem with
these posts is that they _only_ consider characteristics of programmers. The
difference between being a mere programmer and a software engineer (at the
risk of offending real engineers who earned that title) is the way the
engineer runs his or her project, from capturing and interpreting the
customer/client's actual requirements at the start, through to QA, deployment
and beyond. Writing a program is hard, but writing the _right_ program and
being sure that it _actually works_ is even harder, and herein lies the
difference IMHO. That all said, this particular article doesn't fall into that
trap, so I'll leave it there.

