Hacker News new | past | comments | ask | show | jobs | submit login

>Are you certain that business systems are written by people who know all three of these things? My conjecture is that most practising business programmers will tell you that "libraries" and "frameworks" exist to solve these problems for them and that knowledge of the details is nice to have but not necessary for employment as a business programmer.

Are there programmers who write business applications without understanding and knowing these things? Yes, most certainly. Are these programmers working in businesses known for using software as a competitive advantage? Almost certainly no. With the exception of AWS, most of what Amazon does (and what made them successful initially) was business software: e-commerce, shopping carts, payments processing. Yet it's clearly that they used in-house software development talent as a competitive advantage (most obvious example is Dynamo's original role as a shopping cart engine which allowed them to handle peak holiday traffic without declining sales).

Libraries and frameworks are great, but they're of no use if the application developer doesn't know they need to use them. An app developer will have to know that Double can't give him precise decimal math, before he'll use BigDecimal. An app developer will have to know what race conditions are before he'll know where to use a ConcurrentHashMap vs. a HashMap vs. a synchronized block vs. ReentrantLock. I'm not aware of an ORM that is sophisticated enough to tell you what sort of index to use (this may also be an omission on my part and there may be ORMs and other tools that will make reasonable default choices and setup indices during the DDL phase).

>"Systems/library/algorithm implementation work" is another thing entirely, but I'm sure we can agree that at this moment in time, there are very few people doing systems work or building libraries compared with the number of people using them to build business systems.

My perception is somewhat skewed: I'm in Silicon Valley and have worked at multiple Internet firms and at an infrastructure (security) vendor as a systems/library implementer (or you can say, "mostly userland systems programmer"). While it's obvious that there's lots of systems work going on in infrastructure vendors, I'd say that least 50% to 75% of engineering in established Internet companies and lead start-ups in that sphere involves building tools, libraries and implementing/fine-tuning algorithms rather than application-level programming. The application developers drive the demands for these tools/libraries/algorithm implementations and thus have to have more than "black-box" level familiarities with them. Very rarely are people also hired just for application development roles: knowing a specific library/framework well won't get you hired, as that may not transfer over to other positions in the company. If you look at the interview processes in these companies, you'll quickly see that they reflect that. The app to infra development ratio will certainly be different at smaller startups (more app, less infra), but the need to hire generalists with strong knowledge of the fundamentals is even greater.

tl; dr Let me say it again: good programmers should know the fundamentals. This doesn't just go for the systems/infrastructure developers, but product developers as well: you may still be able to get a job without knowing these basics, but you'll be "locked out" of the most lucrative jobs in a given industry (or even out of whole industries).




good programmers should know the fundamentals. This doesn't just go for the systems/infrastructure developers, but product developers as well: you may still be able to get a job without knowing these basics, but you'll be "locked out" of the most lucrative jobs in a given industry (or even out of whole industries).

I agree with this statement, but I sing in the choir. I suspect that everybody else on HN signs in the choir as well.

Jeff Atwood once pointed out that he wasn't trying to write for his readers, he was trying to write for the millions of programmers worldwide who don't read any blogs at all. Most of them don't work in "The Valley."


> Jeff Atwood once pointed out that he wasn't trying to write for his readers, he was trying to write for the millions of programmers worldwide who don't read any blogs at all. Most of them don't work in "The Valley."

Agree and disagree. Yes, library implementers should think about application developers and the problems they're solving first and foremost. One of the most interesting developments lately has been the work on making concurrency accessible to application developers, which illustrates "and disagree" part: I used the example of Doug Lea's beautiful work on java.util.concurrent to show that while an application developer (or even a systems implementer without a good cause, for that matter) shouldn't have to implement lock free data structures themselves, they have to ultimately understand what lock free data structures solve and don't solve in order to be aware of them and know where to use them.

Lastly, one of the recurring themes of articles I see on this site is about creating a "The Valley" elsewhere (and I don't just mean Seattle, New York, Tel Aviv, etc... - tech cultures in each are more similar to each other than they're different). Perhaps that's something to ponder: is there a culture of "cut and paste and clock out" or "build software that's an asset and not a liability"?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: