Hacker News new | ask | show | jobs
by DanielBMarkham 3443 days ago
Learn patterns and pop up the abstraction level.

There are only a few patterns in programming: imperative, OO, functional, etc. Learn those.

There are only a few abstraction levels in problem solving: meta, business, system, physical. Learn those.

There are only a few types of patterns in ML and Big Data. Looks like it's time to learn those.

But the principle is the same. Learn the patterns of various forms of solutions, not actual languages or tech (they'll be required, of course, but they're only a prop). Be able to move between these various patterns. Then deep dive from time to time on various projects in each area.

We've passed the point where a person could keep up long ago. Now it's simply about being both broad and deep at the same time. T-shaped people. If you want to make a lot of money you can be that one guy who knows everything about some tiny point -- but you'd better hope that point doesn't become obsolete in ten or twenty years. I've seen this happen far too often in tech.

2 comments

I've wrestled with this question virtually since the day I began coding professionally:

Should I become an expert at one language/domain, or, should I constantly learn new things and change roles?

I've done the latter, and I don't know yet if it will have been worth while. I worry about being a "jack of all trades, master of none". Yet, as you point out, a master of one trade had better hope it doesn't become obsolete in their life time.

So my hope is that the investment in learning, and adapting, will pay off in the long haul. I can write an iOS app, I can write an android app, I can code a backend server in scala + akka, or I can write a backend server in PHP. Can I do these things as well or as quickly as a master in each domain? Certainly not.

You say "or" but it can be "and". Best is to be an expert in one, "and" having a jack of all trades experience. I.e. you can specialize in front-end work with framework X, but doesn't mean you can't have experience with optimizing db queries. I think a big part of how to do that is just to stay curious and learn new things for the fun, while having a go to language to get things done efficiently.
> You say "or" but it can be "and". Best is to be an expert in one, "and" having a jack of all trades experience.

Whether that is possible depends on the definition of "mastery" that you use, and how broadly you construe "all".

TL/DR: Even generalists have become much more specialized over time.

Consider that "web design" circa 1996 used to include project management, end-to-end development, PR, search engine placement, graphic design, copy writing/editing, information architecture, browser testing, server administration, domain registration, email configuration, etcetera, etcetera.

Over the past two decades, these tasks and many more besides have swollen to bursting, splitting into entire subdisciplines (some of which have endured, others not so much) and in some cases re-merging into new hybrids.

There is no way for anyone to maintain more than passing familiarity, much less competency, with every aspect of building and launching a non-trivial website (much less a web application). At best, we'll wing it on personal projects, or even skip major .

These days, what passes for a generalist is the "full-stack developer", which pretty much leaves off everything that doesn't have to do with code, or outsources tasks like design to 3rd-party services (eg. Netlify), libraries (eg. Bootstrap), themes, and so on.

I expect this trend to continue and even accelerate, so don't drive yourself nuts trying to keep up with the developments across everything you do today. I guarantee that whatever you consider to be the set of skills a generalist should understand now, it will get narrower over time (but not shorter), and we will have as many kinds of generalist as there are specialists today.

I am pretty sure that the "serverless" trend will lead to a new breed of "middleware developer" that works on various sorts of smart caching proxies, for example.

My advice is to try and be strategic in the things you drop and no longer keep up with, and keep the things that you do maintain competencies in adjacent to each other and to one or two main areas of expertise.

Do you mind expanding a little bit on the "few types of patterns in ML and Big Data". Do you mean models, pipelines etc or something different. I am studying ML in grad school and I'm seeing way more patterns than just a few, almost too many to be honest if by patterns you mean models. I'd love to hear your view and what you meant by only few types of patters.