Live data from Hacker News

Top Surprises When Starting Out as a Software Developer

henrikwarne.com

31–40 of 79 posts

Re: Top Surprises When Starting Out as a Software Developer

#31
post #2

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…

For christ's sake. I've met far too many people with Uni degrees who don't know what a B-Tree is, or even what a linked list is (truly scary).

Re: Top Surprises When Starting Out as a Software Developer

#32
post #2

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…

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). N…

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.

Re: Top Surprises When Starting Out as a Software Developer

#33
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.

Re: Top Surprises When Starting Out as a Software Developer

#34
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

Re: Top Surprises When Starting Out as a Software Developer

#35
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...")

Re: Top Surprises When Starting Out as a Software Developer

#36
post #32

Earlier quoted context omitted.

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). N…

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(…

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.

Re: Top Surprises When Starting Out as a Software Developer

#37
post #2

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…

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.

Don't conflate "self-taught" with ignorance. I'm 85% self-taught (I was a math major in college, and I took a few CS courses but not enough to become a serious coder) but I've picked up a lot of that stuff, on account of curiosity, later on. Whether someone learned how to program in school or in the trenches matters a lot less than whether they had the curiosity to actually learn it, whether than a "get 'er done" attitude that leads to no real knowledge.

There are a lot of people who pursued CS majors and evidently did well enough to get good jobs but, when they got out into the real world, turned out a bunch of VisitorFactory enterprise crap. Methinks they should have drunk less in college.

Re: Top Surprises When Starting Out as a Software Developer

#39
post #12

Earlier quoted context omitted.

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

:) 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.

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.
Post reply on HN