

Top Things Every Software Engineer Should Know - nikosmar
http://www.javacodegeeks.com/2012/05/top-10-things-every-software-engineer.html

======
rickmb
That's not a bad list of things to strive for, but the whole concept of "this
is what I know, I'm awesome, so this what it takes to be awesome" puts me off.

People can do perfectly well if they are lacking in some of these areas,
especially if they bring something else valuable to the table.

Also, I don't agree with the assumption about younger and senior engineers.
Whether you focus is on technical or soft skills should be a personal thing,
not a function of age. This exactly the attitude that tends to force older
engineers into management and out of technical roles.

~~~
benihana
Furthermore, it seems like the kind of technical people I've who've been quick
to talk about their people skills or emotional intelligence have been the
worst kind of oafish moron.

------
casca
1) Fundamentals of Emotional Intelligence

2) Understand the Business of your Customer

3) Minimum One Programming Language for each Mainstream Development Paradigm

4) Know your Tools

5) Standard Data Structures, Algorithms and Big-O-Notation

6) Don't Trust Code without Adequate Test

7) Basics of Project Management, Lean Management and Agile Concepts

8) Key Metrics of Software Development

9) The Root Cause of the Last Defect

10) Understand the Infrastructure

Author says that the list is not ordered.

------
balloot
Hey look, it's yet another HN list of things "Every Programmer should know",
followed by a list of everything the author knows! Funny how that works.

~~~
Retric
It's better than most lists, one of each (procedural programming languages,
object-oriented programming languages, functional programming languages,
declarative programming languages) vs learn a LISP.

~~~
balloot
Well, I am pretty confident that the vast majority of programmers do not know
both a functional and a purely procedural language. In my book, "knowing" a
language entails having used it in some significant piece of software at the
very least. Most programmers absolutely have not done this in ANY procedural
or functional language, and very few have done significant work in both.

I guess my issue with these all-too-common HN "things everyone should know"
posts is that inevitably 99% of programmers don't know all the things everyone
"should" know. If you took the posts at face value, you would feel very
inadequate.

A more appropriate title would be "Things I know. Look at how awesome I am!"

------
marcusf
As good a list as any, with just a few nitpicks; I'd like the story on (1)
elaborated a bit more. Explaining to your manager that your perception of
reality differs from hers doesn't seem like it'd warrant losing an ally in the
company.

As for (8), I'm not a very metrics driven guy when it comes to my code; Beyond
test coverage I've no idea what the key metrics of software development are
(at least in "the small", eg not business metrics). Would anyone want to
elaborate?

~~~
brandall10
Regarding #1, I've found that it's best not to usurp higher management or do
anything that exposes questionable decision-making in front of their peers.
Never do it in email chains or meetings.

Whenever I've had a situation like this I do it in strict confidence and don't
put it in their face, almost always say to the effect "hey I think I found
something, can we grab a room" and go straight to the whiteboard and begin
drawing, and use language like "so check this out... I'm a bit worried about
this, what do you think?" I let them arrive at the same conclusion I did, or
at least start a healthy debate. The great thing about doing this is sometimes
you are wrong, maybe not technically, but there are other considerations that
went into the decision that you're not aware of.

Also I've learned to not overstep my own bounds, when I have issues with
another dept I don't go rogue and knock heads, but go to my own supervisor and
ask if they can talk to the sup in that dept and get back down to their
respective staff. The only exception to this is for time critical issues, I'll
send an email blast to all involved parties first, then walk around and talk
to people - ask them if they have time in their schedule to look at something,
if not who else they might be able to introduce me to, etc.

Basically everything I learned about dealing in a corporate environment was
through making tons of my own mistakes and watching the tv show The Wire and
following the "Chain of Command" and seeing quite a bit of Jimmy McNulty in
myself :).

All this said, the biggest blowup I ever had was only a year ago, it cost me a
relationship with a director a couple levels above me, and it was the result
of actually doing something that probably saved the company a cost in the 6
figures for only 3 days of work... it was a combo message of "great job... and
you made me look like a fool". I totally get it, I would feel the same way if
I were him. But it was still the right thing to do, and sort of a signal that
perhaps the corporate world is not for me - or at least that one particular
environment. YMMV.

------
gyaresu
I'm sorry, you seemed to have an interesting story going there but the
spelling and grammar put me off finishing it. I think this says a lot more
about me than it does you however. (cue next commenter finding the flaws in
this comment)

~~~
wyclif
I've never been able to figure out why it's seemingly so difficult for many
engineers to understand how spellcheck works.

~~~
Bruce_Adams
The errors I saw (before giving up) would not be caught by a spell check. I'll
go so far as guessing that a blind spell check was run, with no human check on
the corrections.

~~~
sujal
Or English isn't their first language. That was my impression. Granted, I
bailed partly because of the grammar, too but that was after realizing it was
a mixed list of soft skills, not algorithms or tools or whatever. Once it
wasn't what I expected, the writing didn't help keep me.

------
acdha
1\. Stop reading anything with link-bait titles like “Top-n”

------
gjm11
Blogspam. Original is at
[https://sites.google.com/site/markussprunck/blog-1/top10thin...](https://sites.google.com/site/markussprunck/blog-1/top10thingseverysoftwareengineershouldknow)
(and yes, the author appears not to be a native English speaker; his name is
Markus Sprunck.)

------
eliben
11) Writing correct English

[or was it auto-translated from some other language?]

~~~
aerique
I read it assuming the writer's main language was not English. Given that, it
wasn't too bad a read.

~~~
chris_wot
I think the substance was pretty good. There's no need to nit-pick on his
English - especially if it isn't his first language!

His English isn't that bad, and nothing about his post shows any evidence that
he isn't an experienced programmer.

------
toolslive
"declarative programming languages(SQL, XSLT, regular expressions, etc.)"

Is it just me or are semantics really shifting?

There used to be a time where 'declarative programming languages' was a group
name for Prolog, Mercury and friends. These days, it seems to mean things like
CSS, HTML, ... which are not programming languages in my book.

~~~
VBprogrammer
Interesting observation. I'd also add that learning Prolog would be a much
more self expanding experience than the languages listed. I've yet to
encounter another paridigim with such a leap in it's learning curve.

------
known
Writing software != Selling software != Selling consulting

------
nsomaru

         >> 5) Standard Data Structures, Algorithms and Big-O-Notation
    

Where would be a good place to learn about data structures and algorithms for
someone who just knows Python and a bit of Django?

~~~
glogla
This is first-year CS college stuff. There are many good books (this
[http://stackoverflow.com/questions/3183240/what-book-to-
use-...](http://stackoverflow.com/questions/3183240/what-book-to-use-to-learn-
algorithms-and-data-structures) stack overflow might help) and there should be
online courses, I think I watched MIT course about a year or two back to
refresh this stuff.

However, especially with Python and Django, you won't be really using this,
unless you are actually making program to showcase some data structure or
algorithm. It is still important, but with high-level languages, the need to
know this is more about the ability to reason about software behavior than
actually coding the stuff yourself. With low-level software (which means GPGPU
too), you would use it too.

Graphs are bit different, but ultimately similar venue.

~~~
acdha
Strong disagreement on that second point: with high-level languages it's in
some ways more important to know algorithms and data structures as you don't
have a compiler hiding inefficiency as well (there are many inefficient C
programs which just haven't had enough data to matter). The answer is usually
“Use the standard library implementations” but knowing which one fits your
problem is an extremely helpful skill.

This goes double for anyone writing SQL queries: ORMs are great at hiding
complexity until you need to write a report and are back to big-O.

~~~
glogla
That is what I meant by saying "you won't use it but understanding it is
important". I should have said "you won't code it" for it to be more clear, as
I meant that most Python probably don't spend their time reimplementing
whateversort, but still should understand what it is and how it works.

------
jsight
The descriptions for intrapersonal and interpersonal appear to have been
reversed.

------
spacemanaki
"Its a good idea to know at least one multi-paradigm programming languages
like Python, Java, C++ or C#"

Those aren't really multiparadigm programming languages.

~~~
jsight
Python and C# are, IMO. Can you explain why you disagree?

~~~
ntkachov
Python maybe. C# (at least when i used it, 3.0)is basically Java and is very
object oriented.

~~~
T-hawk
C# is fundamentally OO (especially considering the .NET framework that it's
tightly bound to in real-world use), but can be used in functional ways. C#
has first-class functions and closures. The LINQ stuff introduced in 3.5 is
amazing to work with, giving C# many capabilities of a list-processing
language also. I love C# and would definitely call it multiparadigm.

~~~
beagle3
> but can be used in functional ways.

Every language can be used in functional ways, including Fortran, Cobol and
assembly language.

I think the main question is "what is idiomatic in that language?" and in that
case, C#, even with LINQ, is still not functional (in the sense that Erlang,
Haskell, OCaml and Scheme surely are, and Python sometimes is).

For example, when you use select in c# over a user-defined collection, the
enumerator might modify global state. It would be bad practice, but it's not
unheard of.

I wouldn't say c# is functional.

------
carguy1983
_"Hey Markus, you forgot to give me the information XYZ in time!"_

The most important thing to realize is that this is a test; he is testing
whether or not you know how to play this game; whether or not you can be
relied upon in the future to work together at this game against common
opponents (not necessarily enemies, but roadblocks). In this case, author
failed the test, and boss's-boss now knows that he will never be able to count
on author to advance a common goal without fear of putting his foot in his
mouth.

I'm a straight male so from my personal experience, women also do this in
relationships. They will test you relentlessly, just like your backslapping
male buddies will give you shit. It's the same exact game, with inverted
strategies. In a sexual relationship or good friendship, you're expected to be
dominant and talk back to these tests, in a professional relationship, you're
supposed to subordinate yourself to organizational superiors.

It's really not that complicated, you just have to use your brains and your
balls at the right times. You don't even really need to be a smooth talker or
a great politician, it's really just about context.

This kind of thing is inherent in an elite education, and inherent in some
peoples' personalities. Most people without an elite education, elite parents,
or natural ability are never taught this, and they basically fuck it up at
every opportunity possible until they catch on or are explicitly taught this.

------
zaptheimpaler
This is brilliant.

