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…
Top Surprises When Starting Out as a Software Developer
31–40 of 79 posts
Re: Top Surprises When Starting Out as a Software Developer
#32My 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…
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
#332) 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
#34Here is an idea for CSCI 344: Identifying When to Throw that Shit Out
Re: Top Surprises When Starting Out as a Software Developer
#35("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
#36Earlier 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(…
I think these kinds of examples are very anecdotal.
Re: Top Surprises When Starting Out as a Software Developer
#37My 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…
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
#38Re: Top Surprises When Starting Out as a Software Developer
#39Earlier 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.
If you need more than 3 levels of indentation, you're screwed anyway,
and should fix your program.