Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Top Surprises When Starting Out as a Software Developer

henrikwarne.com

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Top Surprises When Starting Out as a Software Developer

#71

Post by jdlshore »

tomjen3 wrote: post #62
michaelochurch wrote: post #41

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

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

> This is why the best programmers are in startups

Oh, come on. Show your work.

For that matter, define "best." [1]

[1] My definition includes people skills.

Re: Top Surprises When Starting Out as a Software Developer

#72

Post by mquander »

lttlrck wrote: post #48
icebraining wrote: post #39

Earlier quoted context omitted.

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.

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.

No, it's not that far from the worst offense. The hardest code I have ever had to read has always been code with ten+ levels of nesting in a big function, where I had to keep a big mental stack of what was necessarily true to be in the branch I was looking at. There is no situation on Earth where four levels of nesting couldn't be broken up into something more understandable; the only reason not to might be for the purposes of microoptimization.

As far as I know, the only worse offenses to readability are jumps or formatting your program like an IOCCC entry.

Do you actually disagree, or are you just going on? If the former, then please give an example of the right "circumstances."

Re: Top Surprises When Starting Out as a Software Developer

#73

Post by yuhong »

mgkimsal wrote: post #28
icebraining wrote: post #4

Earlier quoted context omitted.

For me, it was the opposite of ignoring performance: the developers of the platform we work on have decided to use floats for accounting, because decimals were "slow".

Relatedly (yet unrelatedly) I worked at a place where the IT team were given a bunch of excel docs to post to the website. They spent weeks taking all the data and created nested div/span sets with hand styling on each cell (because certain IE versions would deal with the styles right unless inline, IIRC), because tables were "depreciated" (sic). the end result looked just like HTML tables, except they were about 5 t…

Yep, it is tables used as layout that is depreciated.

Re: Top Surprises When Starting Out as a Software Developer

#74

Post by yuhong »

lttlrck wrote: post #47
squonk wrote: post #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…

Maybe they read this: "Things You Should Never Do, Part I" http://www.joelonsoftware.com/articles/fog0000000069.html

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.

Re: Top Surprises When Starting Out as a Software Developer

#75

Post by vorg »

mgkimsal wrote: post #17
trekkin wrote: 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…

I suspect the "self-important people like this" that trekkin is talking about are those who tell IT to "copy every program (and call) in the codebase, add 'Acme' to the front of all the names, and overwrite a clone of the present general data with Acme's data. Why can't this simple task be done by the end of the week, so I can 'deliver a business solution' to Acme next week?". This is just an extreme case I've seen of how the legacy code in many corporate IT depts consists of thousands of copies of the same basic code patterns.

Re: Top Surprises When Starting Out as a Software Developer

#76

Post by mgkimsal »

yuhong wrote: post #73
mgkimsal wrote: post #28

Earlier quoted context omitted.

Relatedly (yet unrelatedly) I worked at a place where the IT team were given a bunch of excel docs to post to the website. They spent weeks taking all the data and created nested div/span sets with hand styling on each cell (because certain IE versions would deal with the styles right unless inline, IIRC), because tables were "depreciated" (sic). the end result looked just like HTML tables, except they were about 5 t…

Yep, it is tables used as layout that is depreciated.

Well, I'd say not even that. When you're laying out a spreadsheet, just use tables then style them as appropriate. My recommendations were summarily passed over, and I don't work there any more. :)

Re: Top Surprises When Starting Out as a Software Developer

#77

Post by gizmo686 »

trekkin wrote: 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…

This is actually suprising to me. I started out as a self taught programmer in middle-school. Very early on I ran into performance problems, and had to spend a fair amount of time making code efficient. I did, and still do, only explicitly try to make code efficient after I see it is a performance issue, but I wonder how anyone can do a large amount of programming without running into them.

Also, even if you never thought of efficiency, or algorithms. If someone describes binary search to you and you cannot implement it, you are still learning to code. If someone asks you to write an efficient search algorithm, I can see those types of people missing it (especially when you consider the fact that for the general case you also need an nlog(n) sorting algorithm.

Re: Top Surprises When Starting Out as a Software Developer

#78

Post by edwinnathaniel »

tomjen3 wrote: post #62
michaelochurch wrote: post #41

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

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

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

Re: Top Surprises When Starting Out as a Software Developer

#79

Post by lurker14 »

ig1 wrote: post #32
mgkimsal wrote: post #17

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

Was that because the author had no comprehension of complexity and couldn't understand what was wrong with the design, or because of a lazy oversight that was fixable once the problem was brought to light?
Post reply on HN