Live data from Hacker News

Top Surprises When Starting Out as a Software Developer

henrikwarne.com

21–30 of 79 posts

Re: Top Surprises When Starting Out as a Software Developer

#21
post #16

Earlier quoted context omitted.

Yes, it's exactly that attitude he is arguing against. Then it falls to people who know what they're doing to clean up after the "just get it done" morons, when it turns out just getting it done means getting it done wrong and badly and slow. Management thinks "oh, it's already done, speeding it up should be an easy job, what's wrong with our new maintenance guys that they take so long to just fix it up?" I use the t…

Surprise, both of you guys are needed! The "get it done" guy, is almost never the "do it right" guy. Some are closer to each other then others... but almost never are they the same guy. The thing is, when you're building that first prototype, the most important thing is getting it out there and proving the concept works! It doesn't matter if you build the perfect architecture that can scale effortlessly if in the end…

I have also been on the side of finishing a new product quickly and imperfectly, and I acknowledge the trade-offs involved. I rail against the "get it done" mind-set in quotes. I find that a programmer who prides themselves on getting it done is, more often than not, a "get it done" moron who means get it done badly. The kind of programmer who thinks "getting it done" means stabbing the code enough times that the bloody wounds congeal just enough to compile. They are not smart or experienced enough to know what they don't know.

Re: Top Surprises When Starting Out as a Software Developer

#22

Earlier quoted context omitted.

Yes, it's exactly that attitude he is arguing against. Then it falls to people who know what they're doing to clean up after the "just get it done" morons, when it turns out just getting it done means getting it done wrong and badly and slow. Management thinks "oh, it's already done, speeding it up should be an easy job, what's wrong with our new maintenance guys that they take so long to just fix it up?" I use the t…

I'm not saying to just 'get it done' because that is really misinterpreting what I said before, I'm saying that the low level, time intensive method is not always the best, especially when you need to push a project soon and time is really running out. Your insinuation that doing something quickly means doing it badly is, in my opinion, unfounded, being productive and speedy is merely a by product of knowing what you…

Fair enough. "Get it done" is a trigger phrase for me, so I responded in too personal an attack. There are many "get it done" morons out there, and I have worked with several, but that of course does not mean you are one. You recognize the inherent trade-offs involved, which I appreciate.

Re: Top Surprises When Starting Out as a Software Developer

#23

Earlier quoted context omitted.

Yes, it's exactly that attitude he is arguing against. Then it falls to people who know what they're doing to clean up after the "just get it done" morons, when it turns out just getting it done means getting it done wrong and badly and slow. Management thinks "oh, it's already done, speeding it up should be an easy job, what's wrong with our new maintenance guys that they take so long to just fix it up?" I use the t…

I didn't read it that way. I also find it ironic that in arguing against self-important people, there is a hell of a lot of self-importance inherent in the post (and yours, too). The degree (or lack of) isn't the issue. Having a CS degree doesn't make you immune to any of your assertions. What you're describing is just a bad programmer . I believe the GP's argument is about programmers with CS degrees who don't 'get'…

Of course I am describing a bad programmer. Your point is well taken, many programmers with CS degrees are terrible, many programmers without CS degrees are terrible, and there are some good among both.

There are of course many ways to be a bad programmer. "Look how smart I am" is one kind, but I don't worry nearly as much about them because I have found that far more often I am dealing with the "get it done" kind of bad programmer.

Re: Top Surprises When Starting Out as a Software Developer

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

Despite being someone with a formal CS background, I completely understand where you're coming from. I've worked on practical applications for the last 5 years with very little consideration for the details of algorithms or the underlying theories behind what I'm doing.

Despite my highly developed pragmatism, I still think understanding those theories at great depth makes me a better programmer.

It's almost subconscious, but knowing how the compiler works, how the processor runs the compiled code, and how everything works at the most basic level gives me a more complete idea of what I'm doing under the hood.

I guess you could say that it's like having a physics degree would make you a better car mechanic, when the reality is probably far from it. But then, I know lots of car mechanics who would benefit from knowing a little more about the theory of their work rather than just practical know-how. It's a fine balance.

Just to respond to your last point: I've been one of those people insisting on doing something the "right" way. I disagree that this is a bad thing, or a sign of inexperience or lack of understanding. Often when I have to argue hard for taking this "right" path, it's because of experience with doing it the other way, and a belief that one would only do it the "wrong" way because of inexperience. So in other words, I have exactly the opposite view on that entire subject.

Often the "right" way to do things takes a little more time, a little more work, but is usually more rock solid in the long term or easy to understand for other programmers. It's more deterministic and predictable, and usually more about good architecture than raw performance (or it should be).

In general you have good practical points that every programmer should be aware of. By no means should real programming be done in an academic and theoretical manner. But at the same time, theoretical CS is provably correct about a vast number of concepts (that is it's business after all), and by no means should they be ignored or looked down upon. The truth lies in a balance between practicality and theory here, and one should never take a side. Look at each situation with the perspective it demands and solve it using the wide variety of tools available to you, and be prepared to accept that a solution might be more theoretical or more practical than you're willing or able to understand.

Re: Top Surprises When Starting Out as a Software Developer

#25

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…

Despite being someone with a formal CS background, I completely understand where you're coming from. I've worked on practical applications for the last 5 years with very little consideration for the details of algorithms or the underlying theories behind what I'm doing. Despite my highly developed pragmatism, I still think understanding those theories at great depth makes me a better programmer. It's almost subconsci…

I struggle between wanting to clarify my 'example' situations more, and not wanting to 'name names' (or implicate people enough based on identifiable information). In two recent cases, scenarios that were being argued for as "right" (as in "there is only one right way, because I have a CS degree") were in actuality subpar options where there was no definable 'right way' (think arguments for which order invoicing/accounting software should process debits/credits in). To some extent there are 'right' ways in some fields, but the real right answer is to work with the business units in question, and determine both what they need now, how to adjust them to another process if there's a compelling reason to change, and document all of it for posterity. In contrast, I was dealing with something built in isolation, undocumented, and justified with hand-wavy CS pseudo-BS. This isn't an argument against CS theory at all, but as much as people have run in to justifications for bad code with "well, it worked and we had a deadline", I've also run in to quite a number of piss poor designs that didn't really work (or required massive work arounds) because someone with a CS degree was given free reign without challenge, and who never understood the pragmatic aspects of the business needs they were purporting to serve. In more other words, I suspect we would probably have the exact same view on that subject (if I'd shared explicit details).

I do not at all 'look down' on CS stuff, but also don't feel that I need to be an expert on every single aspect of every single aspect of it to get things done. For example, my Linux desktop worked pretty well for my needs both before and after Linux kernel scheduling patches. When I read about them, I could understand what was going on, and if I was deep in the kernel, might even have been able to identify what/where to do. I appreciate and benefit from proper and efficient algorithms in libraries I use, and can (if need be) identify a particular library that's suited for a particular project based on the algorithms they use (and may even dip in the code to verify it's doing what I really need).

My own background is that I did 6502 machine code (by hand, no assembler) in the 80s (not professionally - I was a kid - did it as a hobbyist), so while I do not claim to be a computer scientist by any stretch, I have a decent conceptual idea of what's going on at the low-level. yes, most of that is out of date today, but I think conceptually I 'get' it. I also don't think it's actually helped that much in day to day work, but, perhaps it has and I just don't see it any more as it might be second nature(?)

Last point(?) - even if what you're doing is technically/algorithmically the most optimal solution to something, please document what you're doing. Even something as basic as identifying "hey, using a bloom filter here because XYZ needed ABC" in some comments will help people coming along who aren't familiar with particular patterns to get up to speed.

Re: Top Surprises When Starting Out as a Software Developer

#26

Earlier quoted context omitted.

I didn't read it that way. I also find it ironic that in arguing against self-important people, there is a hell of a lot of self-importance inherent in the post (and yours, too). The degree (or lack of) isn't the issue. Having a CS degree doesn't make you immune to any of your assertions. What you're describing is just a bad programmer . I believe the GP's argument is about programmers with CS degrees who don't 'get'…

Of course I am describing a bad programmer. Your point is well taken, many programmers with CS degrees are terrible, many programmers without CS degrees are terrible, and there are some good among both. There are of course many ways to be a bad programmer. "Look how smart I am" is one kind, but I don't worry nearly as much about them because I have found that far more often I am dealing with the "get it done" kind of…

It'd be interesting to trace at what point the "look how smart i am" developer turns in to a "get it done" developer, vs drops out of the field.

Or to track how many people might self identify as a "get it done" developer who might be labelled as a "look how smart i am" developer (and vice-versa).

Re: Top Surprises When Starting Out as a Software Developer

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

>> 2. Few Clever Algorithms

>> 1. Complexity from Aggregation

Re: Top Surprises When Starting Out as a Software Developer

#28
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 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 times as large in HTML, and not anywhere easily as manageable nor usable by screen readers.

"tables are being depreciated - everything should be done with divs" was some mantra at this place for months, and there was no amount of logic or argumentation that would make anyone see sense. Even something like pointing out the W3C spec explicitly still had TABLE as a defined element... that was just false, because tables are "going away". This was... 8 years ago(?)... we still have tables. :/

Good times. :)

Re: Top Surprises When Starting Out as a Software Developer

#30
post #6
post #5

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.

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?

I would suggest you see some of Uncle Bob's talks/videos (starting with http://www.cleancoders.com/)
Post reply on HN