
Top Surprises When Starting Out as a Software Developer - henrik_w
http://henrikwarne.com/2012/08/22/top-5-surprises-when-starting-out-as-a-software-developer/
======
trekkin
My biggest surprise - many developers, even in senior positions, are self-
taught and cannot properly implement even basic stuff like binary search,
don't understand basic performance considerations around algorithm complexity.
Their mindset is "we are using high-level languages; specific algorithms and
performance considerations are properly addressed for us by the language
designers, we are doing real stuff and not some theoretical CS BS".

This varies by the company, but many companies are full of self-important
people like this.

~~~
mgkimsal
I fall in to that camp. I don't look down on 'theoretical CS' stuff, but it's
_rarely_ ever even had to be a consideration in projects I've worked on, which
has included ecommerce systems selling billions of dollars of stuff (large
qtys, small price per item), real time reporting of financial data, and
numerous other projects requiring a degree of scale or speed or both (php, vb,
java and other stuff over the years).

Not everyone works on facebook, nor is everyone writing real-time device
drivers, nor is everyone writing something that will explode up in users
tomorrow, devastating the business if not every customer is served in less
than 50ms.

I may be one of those in the 'get it done' camp, but I've also learned over
the past several years to opt for using well-known libraries when possible, to
take advantage of the expertise and skills that I don't have (yet). 15 years
ago, I was firmly in the 'write it from scratch and focus on performance,
tightness, elegance, etc' camp, but not so much today. Part of that is because
we simply didn't have the wealth of free software libraries we do today, so
you _had_ to write more stuff from scratch, but that's not as much of an
excuse today.

I've yet to have to write a binary search after 17 years in professional
software development, and my projects have not suffered because of it. I had
probably a good 10 years of hobbyist time before that, so I probably have
simply picked up 'good' patterns to common problems without necessarily
knowing the specific CS theory or names behind them in some cases.

All that said, my answer to performance issues in my apps is generally not
'throw more hardware at it' - I will profile to look for bottlenecks, isolate
specific areas and rewrite sections of code to make them more performant,
which sometimes means changing how data is organized/stored, or modifying
queries, or something else.

Lastly, while I think I understand the type of person/attitude you're talking
about "full of self-important people like this", I don't think I see myself in
that particular camp (but of course, no one ever does, right?). There's a
degree of pragmatism that needs to happen in 'real world' software dev (isn't
agile all about "you ain't gonna need it"?). I've also had to 'clean up' after
enough other developers over the past 17 years - _including myself on a number
of occasions_ \- that my perspective may be sufficiently different from the
type of people that work in company X for 10 years and rise to the rank of 'sr
dev' only ever having worked in one or two places. Or maybe I'm just a self-
important ass who's justifying himself too much in public?

EDIT: One other thing that has popped in to my head - I've worked on more than
couple projects where other people on the team (before me or concurrently)
insisted on certain things being done "right", simply because that was the
"right" way. Two things were apparent - they typically didn't know any other
way at all (lack of experience) and they had no understanding of what the real
use of the application was - never talked to end users or other depts/units,
and were creating far more work for everyone else by not implementing things
differently (in their minds, 'compromising on correctness'). Couple different
scenarios in the past few years spring to mind.

~~~
ig1
Some real world examples I've seen where people have screwed up because of not
understanding theory:

A graphical toolkit system that stored all the styles applied to components as
a linked-list, but each element included a pointer to the the head of the
linked list and everytime a new component was instantiated it was added to the
head of the linked list. Which meant that creating a new graphical element
went from O(1) to O(N) and caused significant slow down (i.e seconds of time).

A well known open-source xml parsing library which stored the attributes of an
xml element in a linked-list, as part of it's xml validation it had to ensure
attribute uniqueness and do that it had to iterate through every attribute.
This means that to insert N attributes would take O(N^2) - again enough to
cause a significant performance degradation.

Iteration through hashtables.

~~~
dreamdu5t
As a selt-taught developer, I know what Big O notation is and I've worked with
many CS grads (including Stanford) who did not take into consideration
algorithmic efficiency.

I think these kinds of examples are very anecdotal.

~~~
mgkimsal
The bigger point is that it's almost all anecdotal - the number of people in
this field is too broad and varied to be able to draw any substantial
conclusions about anything, imo.

------
mtkd
1) The aggregation of marginal gains - most enterprise software is crap, most
enterprise teams are lazy - if you consistently and repeatedly improve the
worst aspects of your app you quickly end up with something that outperforms
competitor software developed with 8-figure budgets.

2) Software quality is inversely proportional to the number of people working
on it.

3) Teaching someone with maths how to code is a lot easier than teaching a
coder maths.

~~~
klibertp
About #3 - source?

------
tzaman
I think it should go without saying, but there is one more point I'd add to
this list: Learning never stops - don't be ignorant.

Suprisingly, I still deal with many developers that write procedural code with
if/else statements, up to 4 or more levels deep, even after years of being
developers.

~~~
trekkin
So you suggest that instead of several if/then/elses a clever recursive
function call should be used, right? And the function should take its
arguments by value, and have zero side-effects?

~~~
icebraining
Why would you need a recursive function? It's just a matter of decomposing
your functions into smaller parts.

~~~
damncabbage
I think trekkin was being snarky about people preaching Functional techniques.
(I don't think said snark was warranted, for the record.)

~~~
trekkin
:)

I'm not against functional languages/approaches. I just think that everything
has its place, and that procedural code and nested if/then/elses are
appropriate in many circumstances.

~~~
icebraining
When exactly are _four levels or more_ of nesting appropriate? This has
nothing to do with functional programming, it's a matter of readability. I
mean, Linux is a completely procedural codebase (with some manual OO), but
even its style guide says

    
    
        If you need more than 3 levels of indentation, you're screwed anyway,
        and should fix your program.

~~~
lttlrck
Why four, or three. Why not one or five... what a silly question/statement.
It's completely subjective and as far as "a matter of readability" it's far
far from the worst offense.

~~~
icebraining
It's not completely subjective. McConnell in _Code Complete_ mentions studies
by Chomsky and others that suggest that few people can understand more than
three levels of nested ifs.

As for being far from the wort offense, well, I try to set my goals a little
higher than "not the worst".

------
dreamdu5t
My biggest surprise - The value of modularity is almost always ignored and
that ivy-league CS grads can be horrible programmers.

------
squonk
Maybe not a surprise, but definitely unexpected, was the number of systems
where, over time, the incremental features had overtaken the original
architecture, but the vendor would not fund a new implementation. I've seen 15
year-old systems that were so byzantine, every feature change broke two
others, and attempts at improvement caused entropy. It was both a huge time
sink and customer satisfaction debacle.

Here is an idea for CSCI 344: Identifying When to Throw that Shit Out

~~~
lttlrck
Maybe they read this:

"Things You Should Never Do, Part I"

<http://www.joelonsoftware.com/articles/fog0000000069.html>

~~~
yuhong
Another favorite example for me BTW is the MS OS/2 2.0 fiasco that IMO is much
worse, involving MS using unethical tactics to attack OS/2 later on. And Joel
happens to be a former MS employee.

------
icebraining
Nowadays it's much more difficult to be surprised, at least if you're
interested in more than just getting grades (which actually rules out plenty
of my colleagues). There's so much information online, plus the opportunity to
work on OSS projects, etc, that none of that really surprised me when I got my
first job a few months ago. Reading TDWTF alone prepares you for the worst ;)

------
jheriko
my biggest surprise (i started in the games industry) was just how low the bar
for entry really was. i could have started 10 years earlier if i had realised
just how truly awful most programmers in the industry are...

------
Shish2k
My top surprise? It's not uncommon to see people using MySQL with ISAM tables
as a serious data store, and then half-implementing ACID properties in the
application's GUI layer.

("Why would you want to put data constraints in the database? The data has
already been validated by client side javascript, making the database enforce
foreign keys too would just slow it down...")

------
michaelochurch
There's a common theme in these posts, along the lines of "OMG I didn't
realize paid programming gigs were effectively business roles". Let me address
what's intrinsic and what's not.

 _5\. People Interaction_

Yup. People skills matter. Programming seems like a great job for asocial
people. It's actually the shittiest job imaginable if you have weak people
skills, because you get staffed with the crappy maintenance projects that have
no upside. (Programming probably has the most variance of any job category;
the best projects are a lot of fun, and the worst grind your mind to sawdust
and produce nothing.) If no one likes you, no one trusts you, and you'll never
get projects where your technical intelligence really matters.

I understand the hate that technical people have for "office politics" but the
only approach that works is to adapt. To figure that shit out so you can laugh
(silently) at the suckers who don't get it instead of being one of them.

 _4\. Writing Matters_

Yes, yes, yes. It really does. My personal opinion is that you're no better a
programmer than you are a _teacher_. We're drowning in technical assets. Most
assets are of abysmal quality because the people generating them never took
the time to communicate what was being done, how and why, but too little code
is not a problem for the software world. We have too much. Too much code and
far too much unmanaged complexity.

People who are unwilling or incapable of teaching others how to use the
technical assets they've created should not be programmers IMO. That's your
job. To solve problems and to _teach_ people how to use those solutions.

 _3\. Software is Never Done_

Further reading: [http://michaelochurch.wordpress.com/2012/04/13/java-shop-
pol...](http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/)

Sadly, this is more a consequence of big-program enterprise methodologies. In
small-program shops, software can be "done". It can actually be finished. The
overarching project continues to expand, but this shouldn't be accomplished by
shoving more kLoC into a working program and diverting it away from the
original vision.

Large, ambitious projects should be structured as _systems_ and given the
respect that a system deserves (such as attention to fault tolerance and
communication protocol). There's no excuse for most of these large single-
program monoliths that ultimately (Conway's Law) become artifacts of parochial
corporate politics rather than elegant, minimalistically simple solutions to
mathematical and computational problems.

I'm a fan of the Unix philosophy and small-program methodology. Solve a
problem. Do it well. Move on. Come back to it _if_ you need to solve another
problem. Not unless. I don't like the big-program methodology, under the guise
of "object-oriented programming", that seems to have won in the contemporary
Java-shop culture.

 _2\. Few Clever Algorithms_

Sad but true. The managers' job is to take cleverness out of our jobs, not
because they're assholes or don't trust us (usually not the case) but because
if our work relied on our cleverness or creativity, then they wouldn't be
doing their jobs, which is to deliver business value reliably. We tend to like
the high-expectancy, high-variance, fun and creative work, but there isn't
much tolerance for this in the industrial world, which would rather produce
the low-expectancy "sure thing". The problem is that Big Software actually
isn't "reliable"; it's just that the legacy costs are paid out later after all
the decision-makers have had a couple of promotions and are far away from the
wreckage.

 _1\. Complexity from Aggregation_

Yes. This is exactly why I hate big-program methodologies. They inject so much
unplanned, unexpected complexity into everything. People should aim for 500
lines of really clean, usable code instead of 20,000 lines of garbage that
barely solves the problem and for which no one really knows what it does.

~~~
tomjen3
>Yup. People skills matter. Programming seems like a great job for asocial
people. It's actually the shittiest job imaginable if you have weak people
skills, because you get staffed with the crappy maintenance projects that have
no upside. (Programming probably has the most variance of any job category;
the best projects are a lot of fun, and the worst grind your mind to sawdust
and produce nothing.) If no one likes you, no one trusts you, and you'll never
get projects where your technical intelligence really matters. I understand
the hate that technical people have for "office politics" but the only
approach that works is to adapt. To figure that shit out so you can laugh
(silently) at the suckers who don't get it instead of being one of them.

This is why the best programmers are in startups -- I do not believe you can
be good at people and computers at the same time. And it is much more
profitable to be involved in people, sadly.

~~~
edwinnathaniel
> This is why the best programmers are in startups -- I do not believe you can
> be good at people and computers at the same time. And it is much more
> profitable to be involved in people, sadly.

Could this also be one of the _biggest_ reasons why startup fails? Lack of
people skill and focusing on technical problems for the sake of technical? Not
to mention lack of communication to know the intend of the code seems to be
the biggest time sink on programmer's productivity.

Of course on the flip side you can always hire the smarter and smarter
developers than the previous guy since you kind of need them to navigate the
previous legacy code base. This seems to be the pattern in our industry.

