Comment by unoti | Hacker News Reader

Comment by unoti | Hacker News Reader

Parent Full thread

> the idea of devoting so much of my free time to studying boggles my mind. Programming 9-5 everyday makes me much less likely to want to do any coding when I get home.

I can sympathize, but I suggest long term you figure out a way to get over this sentiment. If you plan to work in the industry for any length of time you absolutely must study to stay employable.

With few exceptions almost every segment of the industry changes how it does things about every six years. What you do now will be pretty out of date in mid 2020. I've been working as a programmer since the late 80s. If I step back in six year increments and look at the technologies I was using, here's what I get:

2011: Python, Django, MySQL, Jquery, Mercurial (not Git).

2005: PHP, CakePHP, MySQL.

1999: AIX, PowerBuiler, VB6, FoxPro, Access

1993: DBase 3, 8 bit embedded systems (68HC11)

At every stage of my career people I've known said there was no need to go learn new stuff. What they're doing will always be in demand. I'm talking about people doing things like ANSI 77 COBOL, RPG/3, and system 36 assembler. They were probably right, I'm guessing there's some orgs out there still using that stuff. But the options get smaller every year.

If you want to have your pick of the best opportunities available and be in control of your own destiny, and want to work in the industry more than 5 years, you're going to have to train yourself.

It'll help if you figure out a way to enjoy the experience and have fun with it.

I'm not attributing anything to either of your claims, but I'll claim that there's a big difference between staying fresh on CS interview stuff and staying up to date with production stacks. Both are probably necessary for maintaining employability at the interview stage to some extent, but the latter is a lot more reasonable than the former. You'll use modern stacks in most new jobs, but you won't use CS minutiae in most new jobs.

You don't necessarily need to study for hours in your spare time to do this. Usually when people talk about studying to pass a Big 4 interview they're talking about brushing up on the algorithm stuff and not learning some new tech. For the sort of thing you're talking about, finding your way into jobs working on cool stuff will often provide the boost that you need.

IMO all but the most serious of side projects tend to not build enough experience to pass an interview for Technology XYZ anyways so unless a company is willing to deal with a newbie, and many are, it doesn't matter that much.

The fundamentals don't change. Merge sort in Cobol is the same as in assembly. The rest is window dressing.

You're right, but the window dressing is the platforms we use to build production software. Other people responding to this comment seem to think that the CS fundamentals aren't worth getting good at. I think both the CS fundamentals and modern frameworks are both worth knowing well.

But then again, it goes back to the question of time. It is already hard enough to keep up with modern frameworks on one's free time. Adding CS fundamentals to the mix makes it worse. All of our free time will be eaten up.

Unless you like to be immersed in that world 24/7, something has got to give.

The fundamentals don't change every six years. Get them down, then do a quick refresher before a job interview.

This is the correct answer. Much of CS theory is timeless. Relational algebra has not changed since it was conceived and applied to create SQL.

True, but you don't write merge sorts anymore. A lot of the fundamentals are valuable to know but not actually used in most situations. It's good you know how TLS works, but you really ought not be writing a TLS library yourself.

You'd be surprised how often tricks used in implementing those fundamental algorithms can be useful in day to day work.

Recent example I can think of was using GLPK to implement a dynamic allocation strategy for some spot instances for a pool of heterogeneous servers. I did not implement my own solver for the integer linear constraints but just knowing that allocation problems can be expressed as integer linear programs helped me tackle the problem in a way that others did not think of.

So I don't really buy the argument that knowing merge sort is useless knowledge because you never get to implement it. The value goes beyond just knowing the implementation. Same goes for other kinds of fundamental and timeless concepts and results.

Sure, but you're the guy who writes the library that I use because I have no clue what the hell you just said! It'd be downright dangerous if I hand-roll anything like it.

I hope that's not the lesson here. I was trying to get at the fact that understanding the fundamentals means understanding and exploiting the connections between seemingly different concepts and that learning and understanding merge sort is not time wasted and will come in handy in all sorts of situations.

When in doubt just remember this Feynman quote

“Right. I don’t believe in the idea that there are a few peculiar people capable of understanding math, and the rest of the world is normal. Math is a human discovery, and it’s no more complicated than humans can understand. I had a calculus book once that said, ‘What one fool can do, another can.’ What we’ve been able to work out about nature may look abstract and threatening to someone who hasn’t studied it, but it was fools who did it, and in the next generation, all the fools will understand it. There’s a tendency to pomposity in all this, to make it deep and profound.” – Richard Feynman, Omni 1979

The point I'm trying to make is that what you're describing as "fundamentals" aren't actually fundamentals; that it's a spectrum, and the "things that need to be known to excel" are not what they used to be. Maybe they never were those things.

There's a heavy bias towards the belief that CS, as it is currently taught, provides the "fundamentals" of software development and design. It does not, at least not as completely as the common belief seems to be. This can be reinforced by the current state of our interview processes. One has to re-prove one's understanding of such fundamental concepts, when the degree should, in theory, be enough, as it is in many other professions.

Conversely, a failure to understand fundamental CS concepts (invert a binary tree) doesn't preclude someone from being a successful software engineer (create homebrew).

Actually the rest isn't window dressing, unless you're working on a very narrowly scoped glorified CS project. Actual engineering-scope projects may or may not require a deep understanding of "the fundamentals" but certainly not to the extent that the focus on them for interviews suggests.

I don't understand what distinctions you are drawing. I don't know what engineering-scope vs CS means.

In other news, every employer under the sun complains there aren't enough qualified developers.

You can be sure that they want more supply in the market to drive down cost! I think it's safe to say that developers are pretty expensive as far as individual contributors go. Especially good ones.

Companies are perfecly happy paying their sales staff huge bonuses for 'value delivered', the fact that programmers are at the beginning of that value chain in many cases and bad at negotiation actually makes them cheap. Even the good ones.

Good ones are spectacularly cheap. 10x developers are a real thing, but I've only very rarely heard of anyone who makes 10x salary as an individual contributor. Those folks are names most in this community would know.

That's different though. Its like comparing learning Angular 2 or MongoDB with grinding through Cracking the Coding Interview. Sure they both involve doing stuff in your spare time, but the former can be (or made to be) much more interesting than regurgitating algorithms.

To each his own I guess. When I find time to get on those hackerrank type sites, I find the algorithm practice and refreshers to be both enjoyable and time extremely well spent in terms of maintaining fundamental CS skills. It doesn't matter if my job doesn't have me implementing graph algorithms every day, it affects the code I write (and decide not to write) all the time. Learning how to weld a few 3rd-party APIs together just isn't enough to be a truly good professional.

Now i am realizing this. Once you accept that the only way to remain in the industry is to work after work you just get used to it, although it still sucks :) .

HC11 in 93? May I ask if you worked at Moto, or were you with a client?

Reply on news.ycombinator.com