[deleted]
Top Surprises When Starting Out as a Software Developer
51–60 of 79 posts
Re: Top Surprises When Starting Out as a Software Developer
#52Earlier quoted context omitted.
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.
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.
Re: Top Surprises When Starting Out as a Software Developer
#53There'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…
> 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. Great point. Or as Daniel Geer et al put it[1] (discussing security, but applicable in general): "The central enemy of reliability is complexi…
Fair point, and I agree, but complexity and creativity are orthogonal.
Managers clamp down on individual creativity and cleverness because they fear complexity, and rightly so, because 95% of software complexity serves no value, and only creates frustration and risk. Their risk-limiting optimization tends to suck all the fun and creativity out of the job, although that's not their intent.
Here's the problem: complexity emerges anyway (Greenspun's Tenth Rule). Force people to use Java instead of high-level languages and they'll invent AbstractFactory patterns and hideous, undocumented DSLs in the name of "object-oriented programming". The problem with software is the same problem that exists in legislation: laws are never unmade. The difference is that no one needs to know or care about horse-carriage requirements from 1730 in Philadelphia, but the legacy complexity in software lives on, making everything unreadable and messy.
Moreover, the end-result of all this unexpected complexity is that most software jobs become a legacy slog, which further reduces the room for creative expression.
Re: Top Surprises When Starting Out as a Software Developer
#54Earlier 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(…
Which graphical toolkit system and xml parsing library are you referring to?
Re: Top Surprises When Starting Out as a Software Developer
#55Earlier quoted context omitted.
Your implying that self taught developers are unable to comprehend basic parts of computer science is really an over generalization, I and many of my co-workers are self taught and we often find that graduates, whilst being intelligent and understanding the more esoteric areas of the profession, are unable to understand certain ideas as 'time is money, don't do it cool when a simpler way will work just as well' and a…
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 subscribe to "get it done" programming. I've never had the troubles you seem to speak of going back to fix the shortcuts though. Interfaces are, for all intents and purposes, black boxes, so your improvements can always be dropped right in with relatively little effort.
I guess if the codebase is a mess of spaghetti, that is another matter. I do always try to get the interfaces right from the beginning.
Re: Top Surprises When Starting Out as a Software Developer
#561) 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…
About #3 - source?
Re: Top Surprises When Starting Out as a Software Developer
#57My 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 o…
You have to be careful, many people who laugh at design patterns turn out crap spaghetti code. At least with design patterns, you are at least attempting to separate traversal from operations on the elements as with visitors. People who don't like them often turn out huge monolithic algorithms which is an even worse crime.
Re: Top Surprises When Starting Out as a Software Developer
#58My 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 cringe in pain every time I read such posts. I'm almost entirely self-taught, but I was teaching myself for nearly twenty years now and am still learning, even faster now than ever before. And I will learn for the rest of my life. Hell, I'm writing a compiler now in my free time for fun (not that it's particularly difficult), I already did almost everything that average CS curriculum covers. Stop, please, assuming that being self-taught is in any way worse than being taught by someone else. Maybe it took me more time to comprehend certain concepts, but my understanding of them is just as good, if not better, than most of the graduates.
I know that what you really wanted to say is that people who lack motivation, passion and curiosity are worse programmers than those exhibiting these characteristics, but somehow you failed and instead wrote that being self-taught means that one cannot implement things as simple as binary search. And this is plain wrong, as is equating being self-taught with programming in high-level languages.
Re: Top Surprises When Starting Out as a Software Developer
#59Earlier quoted context omitted.
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 o…
You have to be careful, many people who laugh at design patterns turn out crap spaghetti code. At least with design patterns, you are at least attempting to separate traversal from operations on the elements as with visitors. People who don't like them often turn out huge monolithic algorithms which is an even worse crime.
Functional programming has "design patterns" but few of them, and those design patterns make so much sense that you stop thinking of them as such and just think of them as the way to solve problems. Referentially transparent functions and immutable records for data are design patterns in the non-pejorative sense, but they simplify code rather than complicating it. These are the two design patterns of functional programming: Noun and Verb. For mutable state (monad vs. ref cells vs. message passing) and for the Adjective problem (type classes vs. inheritance vs. functors) there is less of a consensus.
Functional programming isn't always the solution, but it's amazing how often it is the right way of doing things. I just wrote some neural network code, because I'm developing AI for a card game, and I used mutable state because back-propogation feels "inherently mutable" and because mutable Arrays are fast (whereas Scala's Vector might not be). I regret doing so. If nothing else, I should have started with the immutable solution and only moved to the mutable one if there was a measured performance benefit. So many bugs are invited in when you start using mutable state.
My problem with Java-the-culture is that it seems to come from a hatred of mathematics and the reality of what programming actually is: solving computational problems, and using abstractions when they simplify solutions. Large-project methodologies with the weird design patterns seem tailored to make the programming process easier for people who failed Calc 2 to manage. To make it something that non-technical higher-ups can understand and commoditize: "We have 38 Java developers, 302 kLoC, 1973 Factories, and 714 Visitors, and we're going to double all these numbers in the next 6 months." (Never mind whether any actual problems are being solved.)
Re: Top Surprises When Starting Out as a Software Developer
#60Maybe 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…
As the link by lttlrck also advocates: throwing shit out can easily be a mistake. More usually, http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea... + http://www.amazon.com/Refactoring-Improving-Design-Existing-... can get you further, faster. Stuff keeps working while you incrementally improve it.