Ask HN: With such fast changes in technology, how do you update your skillset? - <AUTHOR> AI/VR and slowly lot more. I am getting quite anxious if my skillset might go obsolete. <comment><USER2> To be honest, it isn't and I don't.

That sounds rather blunt, but most organisations _that aren 't startups_ don't change technology quickly if at all. C++ has served me well for two decades; I probably ought to adopt C++14 but on the other hand my current job requires that the codebase build with a 2008 compiler.

I'm also extremely skeptical of the extent to which AI and VR are _new_ , as opposed to incremental improvements to technology which takes it over an adoption barrier. Have you seen the 80s VR headsets? SHRDLU? The "AI winter"?

If you're worried about this stuff then it's helpful to develop a level of knowledge about it that's slightly higher than _Wired_ but lower than actual implementation detail, in order to talk about it in interviews. You can then pick this stuff up as you go. Machine learning in particular is maths-heavy, matrix algebra in particular, and _that_ 's never going to go obsolete.

I also agree with the commentators who are saying that you should ignore the latest flash-in-the-pan frameworks unless you really have to to get frontend gigs.

<comment><USER3> I completely agree with you.

I started in this field in 1992. I've seen the coming and goings of many flash-in-the-pan technologies.

If you are a dev and are selling yourself on your skillset, ask yourself, "is this sustainable?" The answer is "no." A fifty-year-old brain simply does not absorb new technologies as fast as a 25-year-old-brain. If your plan is to continually adopt new cutting edge technologies in order to stay marketable, I politely submit you need to rethink your long term plan.

As an almost 50-year-old, I promise you that the world is not a gentle place for older devs. Plan your exit into management, a related field, or some other job altogether. If you expect to be a coder at age 50 you're going to be disappointed.

As for me, I jettisoned the "technical skill set" war decades ago. I do not sell myself on my technical skill set. I sell myself as the ultimate generalist. This comes with its own set of problems. However, it has allowed me to age more gracefully in my field, because I do not create the expectation that my primary value-added is code generation.

<comment><USER4> > Plan your exit into management, a related field, or some other job > altogether. If you expect to be a coder at age 50 you're going to be > disappointed.

I'd like to simultaneously disagree and agree with you. If you were a 50 year old coder 10 years ago, then your only hope of remaining in the tech industry would be to add "Manager" to your job title. If you are a 50 year old coder today, that's still a sound direction to go, but increasingly becoming less necessary. If you'll be a 50 year old coder 10 years from now...I think you'll be ok.

Yes, at 50 you almost certainly cannot crank out as much code as you can at 20, but so what? As a coder it is important to understand that most problems in technology are _not_ solved with more code, but less. That you will generate less code at 50 should be seen as a benefit. The advantage you have at 50 over someone who is fresh and new at 20 is that you can recognize that there is very little that's happened in the last 30 years that is _genuinely_ new.

So, if you are 20, go ahead and spend your weekends on side projects learning the latest frameworks. As you continue to do this over the years and decades, shift to focusing more on patterns. By the time you reach 50, you might only generate half as much code as your younger colleagues, but you should be able to solve problems with a quarter of the code required, still making you twice as efficient as them.

When coding was new, code was the only metric by which to measure coders, and non-technical management types would view anyone who generated less code as less valuable. If you're not writing 500 lines of code a day, the argument goes, then you should be managing coders who can. But management and problem solving are not a completely overlapping skill set. Some engineers make good managers, but most do not.

Luckily, the more technically inclined individuals that populate the ranks of company management, the more this is being recognized and the more these companies are willing to hire the 50-year-old-coder-who-codes-less-but-solves- more-problems.

<comment><USER5> I'm seeing a lot of mythic stereotypes here. I am a 52 year old full time coder, and have been actively developing since taking a college pascal class at age 11.

> If you were a 50 year old coder 10 years ago, then your only hope of > remaining in the tech industry would be to add "Manager" to your job title.

People outside the startup bubble value delivering, regardless of age. Developers outside the startup bubble work consistently in a few areas of technology, they develop deep personal understandings with cookbook / solution / frameworks they personally authored enabling them to construct stable solutions that expertly address the problems being addressed.

Essentially, if you remain a "coder" and you use your brain at all above simply being a coder, you will become a software scientist. I never start anything from scratch, as I have about a dozen application skeletons ready for various specific purposes, plus similar libraries I wrote, plus a knowledge of several large commercial SDKs, and developer experience in several major FOSS applications. The work that I do now would give my 20 or 30 year old self a heart attack with the large scope, number of complex technologies, and the time frame I'm expected to deliver. But I've been writing code for 40 years now, and I may bitch at my tools, but it will deliver, it will be well written, fully documented, and so on because anything less just creates technical debt.

If you like writing code, start acting like a scientist about it. Few developers do, and in time you will accelerate away from your peers into a truly enjoyable professional space very few seem to occupy.

<comment><USER6> > I never start anything from scratch, as I have about a dozen application > skeletons ready for various specific purposes, plus similar libraries I > wrote, plus a knowledge of several large commercial SDKs, and developer > experience in several major FOSS applications

I've had a project manager (very insightful guy) tell me something similar before. He said "as you get more experienced you'll (ideally) write less code and instead reuse code from libraries you've written in the past". I've always wondered how that works for someone? I'm assuming certain projects will have requirements where specific technologies would be used in the front-end and persistent layers depending on the kind of project you are building and so those wouldn't be as reusable but perhaps algorithms you've written before might be reusable on the computational side of things. Like perhaps if you had a library that handles very advanced moving cost calculations you could ideally use that same library in different software forms (mobile, web, desktop, command-line).

Edit: Git might be a good example of a library that can be reused a lot and used within many kinds of applications (IE: inside web app, within IDE, from command-line, desktop app, etc)

<comment><USER7> Git is not a library, it's a program. There are, of course, libraries in many languages for using git[0] from within many other kinds of applications.

Another example of a library would be libjpeg[1] for reading and writing the jpeg image format and dealing with all the different ways the format can be adjusted, which gets incorporated into many applications, for example ImageMagick[2].

Basically, a library consists of code that is intended to be reused by calling it from other code.

[0] It's astonishing how often this gets reinvented. Here are just Python libraries: [https://pypi.python.org/pypi?%3Aaction=search&term=git](https://pypi.python.org/pypi?%3Aaction=search&term=git)

[1] [https://en.wikipedia.org/wiki/Libjpeg](https://en.wikipedia.org/wiki/Libjpeg)

[2] [https://en.wikipedia.org/wiki/ImageMagick](https://en.wikipedia.org/wiki/ImageMagick)

<comment><USER6> > It's astonishing how often this gets reinvented

Wow, I'd only heard of libgit2 before. I can't believe how many git-related python packages there are. Yes git isn't a library, it's a program like you said, good catch

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> It may not be in the spirit of HN, but deliberately being 3 years behind on the latest technologies is a really good way to stay employable without driving yourself mad keeping up with the latest and greatest. After 3 years, the flash-in-the-pans and the duds have been winnowed out and you can just concentrate on the stuff which will earn you paying gigs.

<comment><USER9> I agree with that. I don't think it's counter to the spirit of HN. I build apps for clients with the tools I know I'm proficient with but I play and hack a lot too. Sometimes that leads to use with client software though more often it doesn't, but learning is always good.

</comment></comment><comment><USER10> 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.

<comment><USER11> 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.

<comment><USER12> 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.

<comment><USER7> _> 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.

</comment></comment></comment></comment><comment><USER13> Have to do side projects. In my past life, I was getting sucked into becoming a very conservative tech stack lifer at a huge, all-encompassing company. Most people that surrounded me, even the good, hard-working ones, were 9-5 and expressed surprise and hostility to learning anything outside of the company bubble. Then one day a new, more active guy joined our team and whipped up a complete REST-based service in a week. My mind=blown. I quit for the startups, and moved on to using dozens of different stacks since and never looked back. The best, most educating moments typically happened outside of work, when you combine the patterns and observations from work with a different stack or a smart outsider friend who chimes in on your daily struggles from a surprising different angle.

Another enlightening moment for me was when I was working on a hobby machine learning project, and shared my design concerns with a brilliant but very much non-ML coworker, and all of a sudden that coworker laid out the whole design in a pretty convincing detail, like he's been doing this work for years. After the initial shock from his seemingly birth-given ML skills, I noticed that he simply takes a lot of good online classes and goes through all the top ML material on the web in his spare time, even though it was irrelevant to his tech focus at the time. Well guess what, two years later he got promoted and he's making that sweet data science money, and guess where he would have been if he only focused on his old day-to-day instead.

</comment><comment><USER14> My current strategy has a bit of complexity and might take an entire blog post to explain clearly. The high level view is this:

Skills vary both in how much the market values them and in their durability. There's often a trade-off between these two characteristics. For example, half a year's worth of study in a foreign language or pure math is only somewhat valuable to the market but that value doesn't tend to decrease over the years. Learning AngularJS in 2013, on the other hand, was so highly valued by the job market that it was a great way for junior programmers with no degree to break into a software engineering career.

I believe it's best to generally focus most learning efforts on durable skills, but occasionally when there's an opening, to flop and focus 100% on an ephemeral skill that's highly valued and appears likely to be even more highly valued in the near future. After capitalizing on the opportunity, return to mostly focusing on durable skills.

</comment><comment><USER15> A lot of the technology on the bleeding edge will be gone in a couple of years. AngularJS v1 used to be the next big thing, now it's obsolete. Who knows if v2 will stick around.

So following the latest technology in _detail_ is unnecessary. Far more useful is just having a broad sense of what tools are available out there; it takes less time, and it's more useful since it gives you access to a broader set of tools on-demand.

Beyond technology, the things that persist are much more fundamental skills:

1\. Ability to read a new code base, and ability to quickly learn a new technology.

If you can do this you don't need to worry about new technologies since you can always learn them as needed. E.g I just wrote a patch for a Ruby project (Sinatra) at work even though I don't really know Ruby and never saw the codebase before. It got accepted, too.

2\. Ability to figure out what the _real_ problem is, what the _real_ business goal is. This makes you a really valuable employee.

Technology is just a tool. More fundamental skills are your real value.

More detailed write-up on how to keep up without giving up your life: [https://codewithoutrules.com/2017/01/11/your-job-is-not- your...](https://codewithoutrules.com/2017/01/11/your-job-is-not-your-life/)

<comment><USER16> While Angular 1 might be 'obselete', there's still a lot of corporations out there with tons of Angular 1 code, and most of them are not going to be upgrading anytime soon. Angular 2 is enough of a paradigm shift that it would require rewriting those apps from scratch, pretty much, and there won't be a business need to do so for another 5+ years for a lot of these companies.

We're still doing new apps in Angular 1 here, because everyone knows it, we can reuse more code, we know most of its quirks and how to squeeze performance out of it, and we can get the apps out the door a lot faster. Eventually we will have a new project where we decide to use something more current, though.

<comment><USER15> The point is not that Angular 1 is bad somehow.

The point is that trying to keep up with _all_ bleeding edge technology is a waste of time, because it's constantly being replaced.

While at the same time you need to learn whatever technology you use at work, which may _not_ be the latest-and-greatest.

</comment></comment></comment><comment><USER17> Depends. I'm shepherding [http://www.airwindows.com/](http://www.airwindows.com/) through a switch to Patreon, by expressing new DSP ideas in a context of very, very old audio plugin frameworks. The dev tools I'm using won't even work on current computers. I code on a time capsule laptop and depend on the very simplified plugin formats I've chosen (generic interface AU and VST) to remain functional. They'd have to break the most fundamental interfaces to kill my stuff (which doesn't make it impossible to do, just very user-hostile)

Don't confuse advances in technology with intentional churn generated by vendors and platforms. The latter is a plague, and it doesn't only cost people money, it costs them productivity. You may be getting confused and mistaking skillset for toolset. Large companies will always be able to replace your toolset and demand you learn a whole new one, because the more you do, the more you'll be locked in to their toolset. If you can abstract out the functions being implemented and express them in different ways, you can take your skillset different places.

Whether you do that, depends on how good you are at finding niche markets. As someone who's stayed in business for ten years selling GUI-less audio plugins with no advertising and no DRM of any sort, I can tell you (1) niche markets exist and they're loyal, and (2) they're small, which is what makes them niche. :)

<comment><USER18> _> Don't confuse advances in technology with intentional churn generated by vendors and platforms. The latter is a plague, and it doesn't only cost people money, it costs them productivity._

Do you think churn is intentional within a single vendor, e.g. to force upgrades? Could churn be a by-product of competition between vendors, e.g. AWS refactored most of enterprise computing into "low-end" services that steadily improved, but were proprietary and increased lock-in.

 _> The dev tools I'm using won't even work on current computers. I code on a time capsule laptop and depend on the very simplified plugin formats I've chosen (generic interface AU and VST) to remain functional._

Is the time capsule laptop for old operating systems or old hardware? COuld the old operating systems work in a virtual machine?

 _> They'd have to break the most fundamental interfaces to kill my stuff (which doesn't make it impossible to do, just very user-hostile)_

Apple tried to get ride of files (!) entirely, but they are slowly making a comeback on iOS, e.g. now you can insert an attachment within an email, with the right application plugin. Social networks have done their best to replace RSS push notifications with proprietary pubsub. WebDAV, CalDAV, CardDAV are thankfully still supported by a few good apps.

 _> niche markets exist and they're loyal, and (2) they're small, which is what makes them niche. _

How do you market your services/products within your niche?

<comment><USER17> Yes, I do. Forcing upgrades is just another way to force sales, and that's competition. Churn happens.

The old laptop is just the most convenient sort of virtual machine. At some point it'll be easier to run a virtual time capsule laptop… however, the physical time capsule laptop is from a time before intense spyware, so there are security issues as well.

As far as niches, Airwindows doesn't market at all. It's only word of mouth, for ten years, with few exceptions (notably, Console2 got reviewed in Tape Op, a trade magazine). This is personal: I loathe getting harassed by marketers so much that I won't even email, much less advertise. I collected a list of the 'Kagi generation' customers who specifically said they wanted to be on a mailing list and hear from me that way. And then I haven't emailed anything to them for months and months :) So, effectively, my business is 'for people who hate marketing so much that they want to do business with someone who will absolutely leave them alone and not bug them'.

By definition this is a niche to starve in, but it's sincere. I really do hate most everything about marketing, so I simply will not do it. Sometimes when I have a notable post or product I leave out the patreon link on purpose :)

<comment><USER18> Haha, new marketing category: product only available for purchase in a 24-hour period that happens twice a year, or on a date decided by the roll of a dice in a youtube video, or by solving a puzzle, or .. :)

<comment><USER17> But you're still saying 'purchase', and my market sector is completely dominated by software piracy to the point where it's choking on sketchy and unreliable DRM.

More like, 'new' marketing category: Trust Building Exercise. Attempt to give everything possible away, and see if social pressure can cause a lot of people to go 'yay!' and throw money. Hence the Patreon with literally no tiers above 1$, with at least half the patrons from 2$ to 10$ on their own volition.

The trouble with that (speaking as someone who has some notion of marketing but chooses to undermine it) is, it's one of those power-law relationships where basically you have to be me to do it :) without ten years of sorta grassroots presence in the industry and a large number of successful products that perform well as software, you can't do it. You can't simply start up and have a Patreon work on those terms, even if your products are exactly as good, and this is a problem.

Solving that would be a very big deal but it's a bit beyond me for now…

</comment></comment></comment></comment></comment><comment><USER19> 3 steps program (specially crafted for the aged)

</comment><comment></comment><comment>===

0\. Assume any "new" thing is worse than the "old" alternative - until proven otherwise.

1\. Critically filter out hype/PR.

2\. You're left with much less to learn.

3\. Invest "out-of-work" time in something really valuable.

<comment><USER12> Yep, totally agree. And I think the more experience you have, the easier it gets to filter out the crap.

</comment></comment><comment><USER20> It depends on what you already know, I think embedded development with systems level languages and hardware know-how is a very durable skill.

On the other hand, some fields like web development have peaked a while ago, I would argue that 2012 was the high watermark. I think it's a very precarious choice of career right now. It has been steadily going downhill since the introduction of trendy front-end frameworks that don't offer any value to the end user (including React, Angular, et al). The culture stopped being about making usable and accessible interfaces for people, and more about "component architecture", "server-side rendering", "tree shaking", that solve problems created by the very tools they are using.

That isn't to say that web development is dead, but I think that the future will be more specialized around certain features of the platform such as WebAssembly, WebRTC, WebGL, Web Audio, et al. And these will be more readily picked up by people with more durable skills, than those who only know the most popular front-end framework.

<comment><USER7> _> The culture stopped being about making usable and accessible interfaces for people, and more about "component architecture", "server-side rendering", "tree shaking", that solve problems created by the very tools they are using._

Speaking as a confirmed cynic, that seems overly cynical. ;-)

The problems being solved by the web framework hamster wheel are those of rising bars for usability and speed, with measurable in $$$ effects (ie. an extra 1s delay could increase shopping-cart abandonment rate by 1.5%). Which matters a lot more at web-scale.

So, these trendy frameworks are solving problems that most developers shouldn't worry about (it is premature optimization) but that matter a great deal to the companies that release them (Google: Angular and Polymer; Facebook: React and Flux; etc.). OTOH, it is tempting to tap into of all the engineering effort that goes into libraries like these. You just have to know where to stop before sinking into the HammerFactoryFactory mire. ;-)

</comment></comment><comment><USER21> Just like you have to fight feature creep in your products, you have to fight "shiny new tool / language / framework" creep in your skillset. Become an expert in your topic of choice and use the best tools to get it done quickly, whether its 20 years old or two. If you spend too much time learning new tech, you won't get it done quickly, but you shouldn't force an old tool to do something just because you don't want to learn something new.

As for the anxiety, turn off HN every so often and just focus on being a good engineer with your current tools. Nothing changes so fast that you can't go a few months or even a year without being in the know. When it comes time to stsrt a new project, spend a week researching the current tools and see how they fit into your stack.

</comment><comment><USER22> Understand the principles behind things. Most stuff is reinventing the wheels of implementation of a much smaller base of theories.

</comment><comment><USER23> To give you some context, I'll answer this as a [largely] life-long consultant. As such, I don't chase technology, I anticipate the trajectory of job growth. I want the project that I decide to work on next to propel me to a project that will likewise broaden and deepen the experience and skillset I have to offer. <p>I also try not to get trapped into working for clients whose only interest in my experience is to recreate one of the last things I did. The easiest way to kill your value is to do the same thing over and over - even twice is too much.

It's true technology progresses in dog years. When you are working you are not learning outside that bubble. When you are between assignments you absolutely must treat that time as a sabbatical to learn something/anything new.

By broadening your skillset through selective project engagement, you are better off than Skippy who has worked on the same application with great job security for 5 years - Skippy will not be someone you will re-encounter 10 years from now unless you are buying a used car and they happen to be the sales person. The industry is self-selective this way. The complacent "I got mine" mentality is toxic to longevity in the industry.

Let me also dispell the meme that sticking to a specialty is a desirable thing. The fact of the matter is that the ocean of legacy code grows exponentially and there is always a need for someone who knows a legacy language or technology. this kind of career trajectory is as desirable as cleaning out septic tanks. There's job security to be had and you'll hear plenty of "Ho, ho, ho - I don't need no stinkin' new fangled whatever" to be indispensible. My advice is not to be that guy/gal.

It is a much harder and a much richer experience to navigate a career in the flow of technology than to get myopically paralyzed by a desire to featherbed where you are today. But your question is "how" to keep up. IMO, the answer is to skim lots of material and only dive in at the last most relevant moment. The generalist is far more qualified that the specialist these days because most companies cannot afford a prima donna - they need people who can perform many jobs and serve many needs.

</comment><comment><USER24> For me, the answer is side projects. I keep playing with new ideas, and use new techs by the way.

It not only allows me to discover the tech, it's also especially important because I refuse to make first contact with a tech by implementing it directly in a production project meant to stay around for years. The most projects I've used a new tech in before introducing it in my main project, the more comfortable I am that I did not do gross mistakes.

For me, it's not the amount of time using a new tech that matters, it's the amount of projects I used it in (because each time, I can try a different architecture).

</comment><comment><USER25> I developed a checklist to spot technologies that are in an early stage of the hype cycle and avoid them.

The following are signals that a technology is in and early part of the hype cycle:

* It has the backing of a major corporation or a startup with a marketing budget.

* There are a lot of rave articles/blog posts about building relatively simple or small self contained applications using this technology.

* There is a small but vocal contingent of users who are passionately against the new technology. Their arguments often link to bugs on the bug tracker, cite edge cases that occur under heavy usage and indicate fundamental oversights in the design as well as assumptions (and often arrogance) on the part of the architects.

* The benefits cited are either A) vague or B) explicitly aimed at beginners.

* Arguments in favor often appeal to authority (e.g. "Google uses it" or "XYZ company use it in production"), popularity ("everybody's containerizing these days") or cite benefits which were already possible.

* A high ratio of talk to action: the technology is talked about on Hacker News a lot but there appears to be very little real life stuff developed with it and a lot of the talk involves jamming it in where it's not really necessary.

* Sometimes I experiment with a technology for an hour or two and I see if there's anything obviously wrong with it or if the criticisms are valid.

</comment><comment><USER26> \- Be aware of new trends. You don't have to learn everything. But pickup and try those that are promising to solve real problems in your current position.

\- You should be able to move back and forth between management and technical positions. They are not mutually exclusive. You can a skill set that allows you to do either. It gives you greater perspective and flexibility. One piece of advice that I was given in college is that even if you are the Director of IT you should leave small (non-critical) pieces of software for you to work on. So you never lose touch.

\- Try to work for good companies. My definition of good companies are those where you can be productive every day.

\- Some skills will be helpful all your life. I learned Unix in 1989 and have used it almost every day.

\- Learn the fundamentals. Data structures, algorithms, relational theory, structured programming, object oriented programming, functional programming, networking, Operating systems, theory of computation, et al.

\- Understand the business domain in which you are working. That makes you extra valuable for your current company.

\- Develop your soft skills. [http://www.skillsyouneed.com/general/soft- skills.html](http://www.skillsyouneed.com/general/soft-skills.html)

</comment><comment><USER27> Focus on the fundamentals. How do you find the write tools and libraries? How do you translate requirements into projects? How can you communicate with other people effectively? How can you learn what you need to know when you need to know it? How do you recognize sunk costs? What makes good code good code, regardless of language? What compromises should you make, and when? How do you ask the right questions?

</comment><comment><USER28> Learn to learn, and focus on your current client/task first instead of technology. People still get paid to write Cobol.

</comment><comment><USER29> 1\. Relevant skills don't change. Your abilities to reason on problems are never becoming irrelevant.

2\. New technologies are adopted, doesn't mean old ones quickly disappear. Sometimes not even slowly.

3\. Area focus. If my area of expertise is networking, what do I care about VR? We can't be generalists any more than we could be 20 years ago.

4\. If you feel like being a generalist, understanding & internalising (basic) principles is more important than being familiar with specific technologies

5\. Critical, transversal thinking. You can weed out heaps of new technologies by understanding _how_ they fit in a system and the tradeoffs they require, before you have to become intimately familiar with them. Base your approach on tangible end-to-end measurements to understand how technologies might fit in a system, and after that you'll have to keep up with a lot less than the various FOTM

</comment><comment><USER30> Well, a critical eye is a must. Just keep away from the noise and pay attention to what would really make an improvement on your current framework/workflow.

For example, I still do my web development in Django or Flask because they do the job, I'm pretty good at Python and most projects don't really need the concurrency Go or Elixir offer.

One of the best recent additions to my skillset was Docker... a lot of people say containers are not a must but they really made my life easier and allowed me to do cool things for clients from different industries.

It doesn't sound as cool as doing machine learning, computer vision or natural language processing, but don't let the AI/VR hype make you anxious, just focus on what you really want to do.

</comment><comment><USER31> I'm more worried about people constantly believing that every new framework is a major advancement for programming and that it's not just something that could be learned in an afternoon (e.g. React). Or about people following the latest hyped trend without learning anything and without producing much other than more hype.

AI,ML and VR are all really interesting, but as we all know they are not completely new and will not likely account for the majority of the future jobs.

Fundamentals are what matter, most of these "new things" are just something that you can learn with relatively limited effort if needed. Classic programming skills, analytical skills or things like the ability to reason about concurrency issues never go obsolete.

</comment><comment><USER32> I learned the hard way about 10 years ago what happens when your current skill set becomes obsolete, since then I've become very focused (and lucky) and only take on really enjoyable and unique projects. That way it's easy to be exited and do a good job during a project, communicate your passion in future interviews and transfer that enthusiasm in your previous projects to potential future employers.

The exact tech choices doesn't matter that much it's more of the overall direction (in my case analytics, in a bunch of varied sub-fields).

Although the top comment has some merit I'd argue c/c++ is an outlier here rather than the norm.

</comment><comment><USER33> I learn new skills at the job, but at the same time I find that it's not enough. What works best for me to really get into new areas and update my skill set is to regularly take MOOCs and then try to find ways to use the new skills at my job.

At the moment I'm taking this course in Deep Learning

[https://www.kadenze.com/courses/creative-applications-of- dee...](https://www.kadenze.com/courses/creative-applications-of-deep- learning-with-tensorflow/info)

</comment><comment><USER34> Beware of those that make it more important to follow the latest trend than to follow their business model (or that just go "what's a business model?!")

</comment><comment><USER35> A great quote from Lambert about what software development is:

1\. Decide what the program should do. 2\. Decide how the program should do it. 3\. Implement these decisions in code.

Only the last part is actually coding.

In other words, as a software developer, you are _not_ paid to type. You are paid to _think_. And the deeper your knowledge and experience, the better tools you have to actually do that. So focus on learning step 1 and 2!

</comment><comment><USER36> I think having a good core is more important than the "latest flashiest framework" / "New Language" / "whatever" at the end of the day it will be your experience that gets you out of the shit, not some new tool! However saying that I think it is important to not let yourself go stale. I worked with a company that had about 6 devs that were doing things seriously old school, they had no interest in upgrading their skills and for someone who likes to keep on top of the new features on languages it was painful to work with them. In the end however, when they left that company they probably found pretty quickly that they were unemployable!

For me personally, I find that I generally have free reign to test out "new (to me) technologies and my experience helps me realise quickly if they are going to be helpful or a bust!

Take any opportunity you can to do a "little project" in something that interests you and then apply it to problems in your work!

</comment><comment><USER9> Like pjc50, for the most part I don't. Last year was the exception.

I've been making web apps since 1998. Last year I learned how to use CouchDB and PouchDB. Before that I used a flat file database and the built-in filesystem to manage data. I used Perl on the backend with just a bit of JS on the front end to run the apps.

I never did learn how to use MySQL/PHP. I looked at it, decided it was a butt ugly way to make websites, and apps and admitted to myself that I wasn't qualified to design secure SQL apps and didn't want to learn because that is a career all by itself.

So I waited for something better to come along and last year CouchDB along with PouchDB hit the mark so I spent the year learning and using them. It was worth it. With those tools I am faster and better.

The years in-between were spent getting stuff done with the tools I was good at using, not trying to learn how to use a zillion other tools to do the same things.

I looked at a lot of newer tools again last year with an eye towards what was "best". There is a lot of cool stuff out there that does some really jazzy stuff, but in the end I decided to take another look at what was "easiest".

I ended up with CouchDB, PouchDB, and JQuery. Easy to learn and incredibly rich APIs with lots of support and example code. There's more than enough in those to learn and keep up with and if I need to add something I'll look for easy ways to do that too.

The truth is, it takes time to be productive with any language or tool or framework you use. It's a scatterbrained approach to try to build software with something new every time you start a new job.

Right now there are tools being built that will make "AI/VR" easier to implement. Wait for the tools.

</comment><comment><USER37> Well about the ones you have said in specific, AI/VR, I do not think they will be a requirement for the majority of jobs in the software industry for quite some time.

I believe that even though technology changes fast, the things you need to change do not move as quickly but that probably depends on the company and technology that company is using in the first place.

Where I am working, we are writing software mostly in Java, some analysis on the data with Splunk and SQL for the database.

Sure enough I had to keep up with Java development but it is not _that_ rapidly. Nevermind the fact that the company only now is switching to Java 8.

That being said, I do like learning new things in the field but they are not the "latest cool things", for example now I am learning Haskell by reading books on it and doing excercises, the normal way to learn a new language afaik.

I do tend to check out things that tickle my interest, lately I have made a small app in Angular2/Dart because it sounded interesting, but by no means have I learned to use them in-depth.

</comment><comment><USER35> Don't until you need to. If you are planning to leave your current job then look at job offerings in the market and learn the tech needed to get one of those jobs. And since the technology _underlying_ whatever tech is currently fashionable hasn't changed the last 50 years, it will be relatively easy to learn enough to get a job. The rest you learn on the job when solving specific problems. I would _instead_ focus on learning the core tech that hasn't changed for 50+ years. Including functional programming, logic programming, how a computer fundamentally works (NAND gates) etc. What you learn from that will never become obsolete. You just need to translate what you learn into whatever the latest fashion framework/language call it and ignore the false hype.

<comment><USER35> For example: people who learned lisp years ago are now laughing about the hype higher level functions (lambdas etc.) are getting. It is ancient technology. Same when Java introduced garbage collection. Yet another ancient technology. However my argument is not that you should learn lisp today to get a job. You should learn it to understand the fundamental technologies that future fashionable frameworks/languages will use. Same goes for type theory. Rust is also using ancient technology (linear types) that you would already have known about long before Rust showed up if you learned type theory. The next step after Rush is of course dependent types.

</comment></comment><comment><USER38> When I was in college, I majored in math and physics. Only two math classes gave me trouble. One was Real Analysis. There were just too many theorems. I couldn't remember them all, and then I couldn't figure out what to use to solve the problems on the test.

Eventually I realized that, out of maybe fifty theorems, only maybe three were used to prove all the others. So I memorized those three, and worked out anything else I needed for the test on the fly.

You don't need to keep up with the Hotness Of The Week(TM). You need to know the fundamentals well, and you need to be able to learn the rest _when you need it_.

</comment><comment><USER39> 3D graphics math is all trig and linear algebra, with some signal processing. You don't have to know that stuff to use unity to build VR apps, but it helps. Those skills will never, ever, be obsolete. Even deep learning is rooted in linear algebra.

The technology churn in other spaces like front end development can be mitigated by learning to read really fast. I don't have deep experience with any one front end framework, but I can inhale the docs and source code pretty fast when I need to get my hands dirty with one. Again, speed reading is a skill that will never be obsolete.

</comment><comment><USER40> I think you're mixing 2 things. First, what investors are investing in (AI/VR), then what kind of jobs will tech companies offer in a near future. I think the second one won't change, what will change will be the visions and missions of the future companies. There will still be software development for a while, even if you work for an "AI" company. These are just hot keywords in 2016/2017

</comment><comment><USER41> I wouldn't let AI & VR worry you- that type of growth in the field means new types of jobs.

As far as updating my skillset, I watch conference talks, and I built a site that has a big index of them: [https://www.findlectures.com/?p=1&class1=Technology&type1=Co...](https://www.findlectures.com/?p=1&class1=Technology&type1=Conference&talk_type_l2_Conference=Software)

</comment><comment><USER42> I'm concentrating on learning stuff that fascinates me. This also happens to be computer science skills that won't go out of date for a while. Some of it discovered before silicon chips! Even if it won't directly help me in my job today or getting a new job, it Will help my career in the long term by making me a better thinker and programmer.

</comment><comment><USER43> Do not update it. Technology is actually painfully slow. Maybe you need to change technology once in ten years (such as moving from C++ to Java).

<comment><USER7> Whoa there, let's not go overboard. Implementing a decadal cadence for switching would require budgeting for about a year of reduced earnings while you build competency in the new platform/language/ecosystem (and the associated client base).

</comment></comment><comment><USER44> If you have the possibility then try joining larger and younger teams at work. Also: be constantly aware of the current state of technology. You can't have a deep knowledge of everything but at least knowing which problems a new technology solves helps a lot.

<comment><USER45> What is the advantage of larger and younger teams in regards to staying up to date?

<comment><USER44> You are right, I did not expand on that. Larger teams bring in a potentially wider set of skills, and your "next" is probably some younger developer's "current" already.

</comment></comment></comment><comment><USER46> Side projects

</comment><comment><USER47> Fundamentals.

I'm a game developer who have worked in 2d social/mobile lately and am now getting into VR. Turns out, if you know how rendering pipeline works, it's not such a foreign land after all.

<comment><USER48> Can confirm fundamentals. The longer i work as a developer, the more i see the importance to have a grip of the basics. For me this is mysql, linux, math rather than new frameworks, languages and build tools.

</comment></comment><comment><USER49> Don't hold on to the bleeding edge so tightly and you won't get cut. It's fine to ride the wave, but don't forget to polish your less specific skills.

</comment><comment><USER50> Asking this question might help - how could I have learnt what I have learnt already in very less time. Writing down steps or rules could help narrow down to current scenario.

</comment><comment><USER51> Here is how it's going for me. For background, over the last few months I've very quickly become adept in deep learning, being able to understand current research papers, read through textbooks, implement my own models with Tensorflow and other libraries, and train real models on remote servers (e.g. AWS). For reference, I have an engineering background but no formal schooling passed an undergraduate degree.

The situation: my early-stage startup is fundraising right now, which can be kind of a time sink. Lots of accelerator/grant/angel applications. There's a good chance we hit our seed round, but also a good chance I'm unemployed next quarter when/if runway runs out.

In either case, I decided that AI, specifically deep learning, would be incredibly important to my career. The startup will need the expertise in the future (so I'll have to understand how to hire people with it), and should I need to find another job in a few months, this is a pretty cool field to learn and I find the work enjoyable (previously was a data scientist but foused more on vanilla regression and convex methods).

Therefore since November I've portioned out 20 hrs/week to the startup focusing on its fundraising and BD needs, which leaves a whole lot of other hours for skills development. Here has been roughly my curriculum:

\- Mathematics review, and basic neural networks. For this I went over multivariable calculus and lin alg, which I've always been fairly strong, by essentially trying to derive the backpropagation derivatives for simple vanilla neural networks. Then make sure I understand derivatives and matrix data organization for convolution, which is a key component of modern ML. Sources: pencil and paper, and lots of Google to answer any of my questions. Time: 1-2 weeks.

\- CS231n online course: [http://cs231n.stanford.edu/](http://cs231n.stanford.edu/) Great summary of modern methods in deep learning, plus more foundational level stuff. I read through all the lecture content and made sure I could work through derivations, because for me at least this cements technical understanding. Some of them are sort of tedious, e.g. manual RNN backprop. Also this course has great and simple software examples, I read through the code to make sure I understood the numerical computation and data organization parts. I also ran a few software examples and played around with parameters for fun (and learning). Time: 1 month.

\- Reading research papers (and online lectures) on applications that interest me. For this phase, I found 10 initial research papers that interested me. The topics for myself included image classification (starting w/ classic 2012 Hinton paper), reinforcement learning, robotics applications, video prediction. This step was harder, can be like learning a new language. Not every paper is going to make sense at first. But go through enough of them and you'll build up familiarity. Sources: can start by searching through reddit.com/r/machinelearning Time: 2 weeks.

\- Learning software frameworks. From the above step I came up with my own small sample problem related to stuff I read that I could test even on my weak laptop (remember, training these big networks requires big computing power). So in this step I started researching different frameworks, and settled on starting a small project with Keras. Sources: google around for deep learning libraries, read up on them, see what you like, and most importantly, have a motivating sample problem that you wanna code up. Time: 2 weeks.

\- Harder problems, more software, more papers. This is where I'm at now, it's sort of like an iterative research loop where I 1) come up with new problems I want to solve, 2) learn more about the software I need to implement it, and 3) search more prior work to gain insights on how I can solve the harder problems. In particular, I've switched over to learning and using Tensorflow, and also learning how to use AWS for stronger computing. So I had to dust off some linux scripting and command line skills too. Like I said, this is fairly iterative and probably closer to "modern research" where learning from my (virtual) peers and experimentation and production are closely linked. Time: from the last month to present.

Overall, in the last 3 months or so at about 30 hrs/week I've added an extremely powerful new skillset to my arsenal that I've been meaning to do for quite some time. I can understand 90% of all modern research in the field, and create useful software to solve data-driven problems. Completely for free as well, aside from the $0.81/hr I pay to AWS for training some networks overnight. This is the type of thing I'd have wanted from a Master's (or even PhD) program, but who wants to go back to school...

Hope this helps someone :) Remember, AI/ML is more approachable than most people think, you just need to start with a solid mathematics background. After that you'll be flying, the field is relatively quick to learn, especially if you like learning through doing.

</comment><comment><USER52> What is your current skillset? Maybe we can help guide you and ease the anxiety.

</comment><comment><USER53> I'm taking a couple courses from Udacity. They have both AI and VR courses.</comment>


Depth of Field - <AUTHOR> https://inconvergent.net/2019/depth-of-field/ <comment><USER2> Since the theory isn't really described here, anyone who wants a tad more might look at the Ray Tracing In One Weekend booklet for a touch of the optics math behind depth of field. Chapter 11 derives a defocus blur. [http://www.realtimerendering.com/raytracing/Ray%20Tracing%20...](http://www.realtimerendering.com/raytracing/Ray%20Tracing%20in%20a%20Weekend.pdf)

> find the new position, w = v + rndSphere(r).

For anyone wanting control over the look of the defocus blur, also known as the "bokeh", random sphere gives you more samples toward the center than the edges. For a circular aperture, it is slightly better & more correct to sample a disk than to sample a sphere, and slightly faster to converge as well. You can optionally use a hexagon or octagon on the disk if you want to get the look of a film-camera type aperture.

<comment><USER3> i would say that what is correct depends on the intention

<comment><USER2> I'm talking about correctness in the physical optics/lens sense. With lenses, light always passes uniformly through the aperture, where sphere sampling is non-uniform.

Intention is totally fine. This is reasonable if you actually intended to do something different than what a camera does, or if the intention is not physical correctness. This blog post seems to be intending to do something _easy_ for picking samples, as opposed to something optically correct. I'm all for easy, but I also think it never hurts to understand the tradeoff you're choosing, nor to present the harder alternatives.

It's also worth considering disk sampling rather than sphere sampling, because it's barely any harder, and it will make the code converge to the same quality something like 2x faster. Sphere sampling spends too much time in the middle and not enough at the edges. Disk sampling only takes a teeny tiny bit more arithmetic. Jittering & QMC methods will also help a lot with efficiency.

<comment><USER3> yeah, i'm going for easy. and also, easily explainable. i like to leave some of the details up to whoever tries it. which is also why i generally don't include code anymore. i guess i could have had more references though.

sphere sampling has the appearance i want. but sampling inside discs with a probability over the disc radius would also work, probably. i didn't try it here.

</comment></comment></comment></comment><comment><USER4> Nice. I created a package to generate similar depth of field images in R, using a depth map/image pair. Also offers customizable bokeh shape and some other nice features.

Github: [https://github.com/tylermorganwall/rayfocus](https://github.com/tylermorganwall/rayfocus) Blogpost: [https://www.tylermw.com/portrait-mode- data/](https://www.tylermw.com/portrait-mode-data/)

</comment><comment><USER5> From his generative collection these ones really stand out:

[https://img.inconvergent.net/img/gen/20170523-193637-305712-...](https://img.inconvergent.net/img/gen/20170523-193637-305712-c98459c-50519fc.jpg)

[https://img.inconvergent.net/img/gen/20170520-230701-136920-...](https://img.inconvergent.net/img/gen/20170520-230701-136920-9458fb5-78b7266.jpg)

It's almost hard to believe they are computer generated. They just seem so organic.

<comment><USER6> It looks like the links you posted are broken because the site owner doesn't allow hotlinking to those images.

Could you post the link to the blog post with those images? I'd absolutely love to see them!

<comment><USER7> Hitting enter in the address bar allows you to access them

<comment><USER8> On Chrome mobile you need to put a '?' in the URL so it thinks it's a new site and doesn't send the referrer.

</comment></comment></comment></comment><comment><USER9> So pretty! I'm going to assimilate this purely for the aesthetic pleasure :D

<comment><USER10> I know this is so hot! And written in Lisp, I'm having a nerdgasm!

</comment></comment><comment><USER8> This could be made a lot clearer with an animated version either changing the focus depth or rotating the view...

</comment><comment><USER11> Why is the randomization necessary?

<comment><USER2> It's not necessary, but it's convenient. What's actually happening here is Monte Carlo integration. Randomness guarantees you get the right answer. It prevents correlation artifacts. It also gives you a nice film grain look when you don't have the time to take samples until complete convergence.</comment></comment>


Tacoli: a simple logging format - <AUTHOR> http://blog.jgc.org/2012/04/tacoli-simple-logging-format.html

<comment><USER2> Nobody thinks about date formats. There are two you should be using in nearly all cases (other than when you want to make a friendly display to humans):

\- ISO8601 (<http://en.wikipedia.org/wiki/ISO_8601>), which is relatively easy to prase, handles edge cases like timezones and similar gracefully, sorts numerically, and has great support in most languages. Specifically, the best format to use is usually the "YYYY-MM-DDThh:mm:ss +Z" one.

\- TAI64 (<http://cr.yp.to/libtai/tai64.html>) if you need more precision than ISO8601.

</comment><comment><USER3> It is a nice idea. But I think writing Logs as JSON is still a lot more practical.

The idea of writing Logs as JSON has been out for a while, and in my experience, JSON is far more practical.

This is also a good article regarding Logs as JSON: [http://journal.paul.querna.org/articles/2011/12/26/log- for-m...](http://journal.paul.querna.org/articles/2011/12/26/log-for-machines- in-json/)</comment>


CoreOS: Managed Linux - <AUTHOR> https://coreos.com/products/managed-linux/

<comment><USER2> "CoreOS delivers supported enterpise Linux OS in a completely new way. It is the world's first OS as a Service — patches are delivered as a continous stream of updates. This means you are always running the latest in terms of stability and security, without the need for major migrations every few years."

are there really no other enterprise rolling releases, that they're pushing this like it's a new concept?</comment>


Why do VCs care about the stock market? - <AUTHOR> http://mlangner67.wordpress.com/2011/08/10/venture-capitalists-and-the-stock-market-why/

<comment><USER4> Most likely, VCs are thinking about how much _their_ investors will give them. If they could splash out in a recession, they would, but they can't. If they don't have much money to play with, they may be better off protecting the best startups that they have already invested in.

<comment><USER5> Yes, fund cycle considerations are realistic concern as a public market downcycle does shift asset allocation considerations of LPs (a shrinking public pie leaves them over allocated in VC), but that still doesn't explain the behavior.

A.) Funds already earmark follow-on round funds for their investments - <USER2> that doesn't change. To the degree that funds DON'T do this entrepreneurs should be VERY wary (essentially VCs are exposing your business to their business risks).... Think about how volatile the stock market can be when it corrects - if a VC is stopping investment based on a market correction that makes them concerned about raising the next iteration of their fund - <USER3> what they are essentially saying is that right up to the crash they were more than willing (to use a aviation term) invest past V1 (the point where there is no abort of takeoff)... which is just reckless.

B.) This would only affect a portion of the VC universe at a time given the length of an specific fund's lifecycle, overlaps between funds within a specific firm, etc. And certain funds (e.g,. top decile performers) shouldn't be impacted at all.

3\. Sorta validates my point about over reliance on the "splash" or home run, and or pushing risk off to later stage investors to generate return.</comment></comment>


Ask HN: When is it time to switch from Shopify to a proprietary solution? - <AUTHOR> The site in question grew to ~ 5 million in annual revenue within a few years. The founder now has the feeling, it might be time to migrate from Shopify to something proprietary, to build something own.
What can be gained doing this switch? What are the advantages of a self made site?
Many thanks for your inputs. <comment><USER2> It seems you picked a solution and are now looking for a problem. If you have to ask these questions, don't have problems with your current setup and perhaps switching is not really necessary. The better questions to ask are:

\- What are the shortcoming of your current site that would require you to have your own proprietary solution?

\- Would the cost of implementing the solution be less than the benefit of the move?

<comment><AUTHOR> Thanks. It makes sense.

I'll suggest these questions to be asked.

</comment></comment><comment><USER3> I think the question has to be the reverse. You found major problems with Shopify and should be asking if self-made site will solve those problems. If you don't have problems, you shouldn't be moving.

<comment><AUTHOR> Thanks for your reply.

I could have added to the description, that an own site might suit the values of the brand better, which are: self-made, attention to detail, sustainable etc.

But your point still stands.

</comment></comment><comment><USER4> I think maybe you're trading Shopify fees you don't like today for Stripe fees you won't like tomorrow, I'd just leave the site making $5m/yr alone and build however many other websites you want.

<comment><AUTHOR> Interesting point, that you cannot really escape the fees. Thanks for your input.

</comment></comment><comment><USER5> Switching to different provider in the middle of $5M annual revenue from all- in-one web services provider to someone else will guarantee to cost fortune and does not guiarantee the benefits. IMHO.

<comment><AUTHOR> Thanks for sharing your opinion. It sounds plausible.</comment></comment>


Google doesn't index my blog and doesn't respond to requests – what should I do - <AUTHOR>

My blog is nami.me and it does not get indexed by google! <comment><USER2> I'm not sure, but the first article is from January 2015. I think that Google need one or two months to find your site.

Clicky: [http://nami.me](http://nami.me)

<comment><AUTHOR> After investigating it using webmaster tools, found out Google recognises my blog as full spam!! however all other search engines indexed that.</comment></comment>


The pitfalls of A/B testing in social networks - <AUTHOR> https://tech.okcupid.com/the-pitfalls-of-a-b-testing-in-social-networks/ <comment><USER2> Many moons ago, OKC had a sort of clever & irreverent blog for stuff like this. It was a great read. There were some classics like " _never pay for online dating_ [1]" and " _The case for older women._ "[2] The first made a convincing case that the cheesy business model (see below for irony) of most dating sites doomed them to suckness. The second made a hilariously quantified (and also convincing) appeal for changing your age preference settings, while actually talking through real social norms and culture.

They managed to deal with touchy dating sterotypes, race, sex. Reading it, you could tell that they were genuinely smart (as opposed to just sophisticated) in their data/analytical mindset. You also got a feel for how the author thinks and where that mindset translates into making OKC.

Anyway, this reads like a linkedin article. Safe, vanilla company blog post. Big contrast. I wonder if the OKC guys writing that old blog 10 years ago new how unique their position was.

[1] Got taken down after they got bought by the target of the post. Accessible here: [http://static.izs.me/why-you-should-never-pay-for-online- dat...](http://static.izs.me/why-you-should-never-pay-for-online-dating.html)

[2][https://theblog.okcupid.com/the-case-for-an-older- woman-99d8...](https://theblog.okcupid.com/the-case-for-an-older- woman-99d8cabacdf5)

<comment><USER3> I read somewhere that they had just 1 guy doing all the data analysis and after they got acquired he/she just was too busy with other work. Thus those type of posts just disappeared.

<comment><USER4> This is actually a hard thing to manage at some companies. Writers often don't have access or knowledge of the data, and engineers or data scientists often have bigger fish to fry beyond some content marketing explorations.

If anyone has found a good way to find that balance and create really solid in-depth data-driven content for there org, I'd love to learn more.

</comment></comment></comment><comment><USER5> I'm currently in the process of getting my phd on this exact topic and I'm always happy to hear the problem of network interference in A/B tests being tackled at more and more tech companies. Here's a small (incomplete) list of (mainly industrial) references to solutions to this problem.

\- Facebook data scientists have an extensive list of publications on the topic: [1][2]. (Dean Eckles is now at MIT).

\- LinkedIn's experimentation team has also published papers on the topic: [3][4]

\- Data scientists at Google have also worked on this topic. One external publication/collaboration I'm aware of is: [5]

[1] [http://www.pnas.org/content/113/27/7316](http://www.pnas.org/content/113/27/7316)

[2] [https://arxiv.org/abs/1404.7530](https://arxiv.org/abs/1404.7530)

[3] [http://www.kdd.org/kdd2017/papers/view/detecting-network- eff...](http://www.kdd.org/kdd2017/papers/view/detecting-network-effects- randomizing-over-randomized-experiments)

[4] [https://dl.acm.org/citation.cfm?doid=2783258.2788602](https://dl.acm.org/citation.cfm?doid=2783258.2788602)

[5] [http://proceedings.mlr.press/v51/basse16b.pdf](http://proceedings.mlr.press/v51/basse16b.pdf)

Disclaimer: this list is heavily biased by experiences I've had through collaborations/internships. I am an author on [3]. Edit: formatting.

</comment><comment><USER6> > In conclusion: A/B testing is conceptually simple, but can be difficult to > execute if your product involves anything you'd consider "social > interaction".

A/B testing is really hard, even when there is no social interaction internal to your application (like a game). The easiest thing to test is marketing for new users. But even that can be tricky, where one group of people might click fewer ads but are higher quality. This is especially troublesome when you can't tell how many friends they invite through word of mouth. And then if you want to implement other features or fix bugs over the duration of the test, that also poisons the results.

And then the number of incoming users you need is massive.

To do a good A/B test that doesn't mislead you is extremely difficult. Almost to the point that for most companies, I don't think it is worth doing.

> So... I guess my final recommendation is that you should hire some data > scientists that like doing experiments.

Like this guy says, you basically need a data science team to do it effectively. If you've got a small team (like I work with), don't waste your time with it. You're better off just adding new features and fixing bugs.

<comment><USER7> > But even that can be tricky, where one group of people might click fewer ads > but are higher quality

This is why I always pull performance metrics in addition to impressions/clicks when running A/B tests. Not being in the media/creative department means I often don't see the creatives i'm asked to analyze the performance of so there are occasionally different creatives that have a stronger resonance with people with a higher propensity to convert. This is itself a learning and could lead to using that sort of creative more for acquisition focused campaigns, rotating it out of the upper funnel ad rotation and coming up with a new upper funnel creative to test for the purposes of building large audience pools.

> This is especially troublesome when you can't tell how many friends they > invite through word of mouth.

Could you provide an incentive (gold/credit/whatever) for each new active user referred which could feed into the evaluation criteria of the test as far as the "value" that a particular conversion brought with it? Then I suppose it turns more into a LTV study.

</comment></comment><comment><USER8> I think OkCupid must have fallen victim to getting bought out and watered down. They've been removing features and making bizarre UI decisions for months now and people are not happy.

Many threads like this one:

[https://www.reddit.com/r/OkCupid/comments/75r2ay/seriously_o...](https://www.reddit.com/r/OkCupid/comments/75r2ay/seriously_okc_fuck_you/do8ewiz/)

<comment><USER9> > I think OkCupid must have fallen victim to getting bought out and watered > down

I'm betting that they run tests for everything and change into whatever direction the results tells them. If people like "slide to the left/right" and a simple UI, no walls of text, quizzes, etc, so be it.

</comment></comment><comment><USER10> The A/B testing example of 500 word limit is a great example of what Soros calls Reflexivity in his books on markets.

</comment><comment><USER11> Here's an idea, don't trust your users and use your intuition.</comment>


Google Killing Inbox - <AUTHOR> https://9to5google.com/2018/09/12/google-killing-inbox-by-gmail/ <comment><AUTHOR> I am always surprised at how Google likes to kill their own products. What's happening inside of the company that they keep abandoning projects? Aren't we at the third SMS app?</comment>


An obscure religion that shaped the West - <AUTHOR> http://www.bbc.com/culture/story/20170406-this-obscure-religion-shaped-the-west <comment><USER2> >. As well, one could well argue that the cosmic battle between the Light and Dark sides of the Force in Star Wars has, quite ostensibly, Zoroastrianism written all over it.

. . . Or Christianity, or Hindu epics like Ramayana, or the Buddhist struggle for enlightenment and non-violence against our darker natures.

>, as well as the inspiration for the legend of Azor Ahai – a demigod who triumphs over darkness – in George RR Martin's Game of Thrones, as many of its fans discovered last year.

I don't think Gerote RR Martin has ever gone on record about that, this is just speculation

>The idea of a single god was not the only essentially Zoroastrian tenet to find its way into other major faiths, most notably the 'big three': Judaism, Christianity and Islam.

Jewish Monotheism was most strongly advocated by the Prophet Isiah. While this was done in Babylon, it was done prior to the birth of Zarathustra.

Also the mention of Renaissance figures mentioning Zoroastrianism, while accurate, doesn't seem to be some much an influence of Zoroastrianism itself, but rather a fascination for Eastern culture that existed at the time coupled with a superficial understanding of Zoroastrianism.

EDIT: Downvoters and contrarians, you seem to have the wrong date for Zarthustra's birth was around 628 BCE to 555 BCE not more than 3000 ago like some people are suggesting for some reason. Also, even if you argue the birth date, his religion wasn't popular in Iran until it was adopted by Darius in the mid 6th Century, so really it doesn't get you anything.

See:

[https://www.britannica.com/biography/Zarathustra](https://www.britannica.com/biography/Zarathustra)

<comment><USER3> >Jewish Monotheism was most strongly advocated by the Prophet Isiah. While this was done in Babylon, it was done prior to the birth of Zarathustra.

Not True! Scholars put Zarathustra 1000 BCE or even as far back as 1700BCE but [0] but Isaiah at around 700 BCE [1]

Also many aspect of Judaism like the story of flood or creation were copied from Epic of Gilgamesh [2] that goes even further back.

[0] [https://en.wikipedia.org/wiki/Zoroaster](https://en.wikipedia.org/wiki/Zoroaster) [1] [https://en.wikipedia.org/wiki/Isaiah](https://en.wikipedia.org/wiki/Isaiah) [2] [https://en.wikipedia.org/wiki/Epic_of_Gilgamesh](https://en.wikipedia.org/wiki/Epic_of_Gilgamesh)

<comment><USER4> Isaiah is a newer prophet when Israel was conquered by Babylon. The Pentateuch is much much older. The argument of Isaiah is about the development of God of Israel was the great of all the gods to their is no other gods.

> Epic of Gilgamesh

The whole argument is to ask when was the Pentateuch was written. The scholarship for this has had many arguments with people placing it in 700 BCE (Which was just crazy especially if you read Hebrew) many are placing it to the discovery of written language. Prior to written language we had a very strong oral history. Both Gilgamesh and the Pentateuch have evidence pointing to the discovery of a written language. We have ancient Hebrew (What a pain to read) and it does show a strong relation with Egyptian discovery of writing.

Another interesting this is the uniqueness of the Pentateuch to the other writings from ANE (I had to read a ton of them). The academic discipline in these writing is really interesting and to say that one influenced another is pretty much impossible to do, but it has been shown since the 1860s onward that archeology have discovered allot of sites that date way before what people were thinking and we continue to learn more and more.

<comment><USER5> Where in Pentateuch does it say that only a single god exists?

Alternatively we have:

When Elyon gave the nations their inheritance, when he separated humanity, he fixed the boundaries of the peoples according to the number of divine beings, for Yahweh's portion is his people, Jacob his allotted heritage.

\- Deuteronomy 32:8–9

</comment></comment></comment></comment><comment><USER6> For some reason the exact dates have become an issue. From Wikipedia we know there is no consensus:

[https://en.wikipedia.org/wiki/Zoroaster](https://en.wikipedia.org/wiki/Zoroaster)

"Dating is uncertain as there is no scholarship consensus,[3] as on linguistic and socio-cultural evidence, he is dated around 1000 BCE and earlier, but others put him in the 7th and 6th century BCE as a contemporary or near- contemporary of Cyrus the Great and Darius I.[4][5][6][7] "

And you can follow the links there.

There are two important distinctions we, who write comments here, should make:

1\. There is a difference between when a historical figure is reputed to have lived, and when the first influential texts based on that figure came into being. The text often has a stronger claim to historical influence and is certainly easier to locate in time.

2\. There is a difference between an abstract idea that someone thought of "first" and the version of that idea that actually birthed the version that we know. So, for instance, if there was a historical figure in a cave who never wrote anything, but merely thought of monotheism, that is not the same thing as a written text that was read by Abraham, or the writer of the text in which Abraham appeared.

All this is just to say, let's be clear on what we are arguing, at least.

<comment><USER4> Just bad academic research. I ran into it all the time as a Theology Student. People from other Academic Disciplines would repeat something without a reference and it would become its own self referencing statement that after further investigation just proved to be some lazy scholarship by people not in the field. Like a historian making chemistry statements.

<comment><USER7> The main point of this article in my opinion, is not so much Zoroastrianism itself, as it is the conclusion that:

" Iran's many other legacies and influences aside, the all but forgotten religion of Zoroastrianism just might provide the key to understanding how similar 'we' are to 'them'. "

and so I would similarly presume that any editorial slant would likely take the loosest scholarly opinion to suit this thesis..

</comment></comment></comment><comment><USER8> The suggestion is that any religion or movement having a theme of Light vs Darkness has its roots in Zoroastrianism.

I guess it's hard to prove that this is the case. Could be a coincidence as well. Such a theme is quite natural to develop in any culture in any moment in time I guess.

<comment><USER9> The most ancient religion we know of, that of the ancient Mesopotamians, featured a war between the god Marduk and the god Tiamet, who symbolize light/darkness chaos/order etc, much in the way later religions do.

My personal belief is that the religions are all describing the same real phenomenon: the way the individual draws order out of chaos to create the world.

In the Mesopotamian myth Marduk (order/light) cuts up Tiamat (chaos/darkness) and casts her pieces across the universe, creating the world.

In the Judeo-Christian myth Yahweh separates the earth (order) and the heavens (chaos) to create the world.

I don't know of a religion that does not repeat this as a central theme.

Personally I see this as evidence that they were all describing the qualities that the ancient believers saw embodied in their worldly heroes and immortalized them through an oral tradition describing the modes of action (a dramatization) which made those heroes admirable, and those phenomena thus appear wherever there is an ancient myth.

<comment><USER10> > I don't know of a religion that does not repeat this as a central theme.

That's probably more because most major religions all arise from a rather small geographic region (the Abrahamic religions from the Middle East, Iranian religions (e.g., Zoroastrianism) from a little further west, and Hinduism, Buddhism, and other Indian religions are only a little further west than that), such that most religions you'd talk about in comparative religion essentially arise from the same place and broadly the same basic tenants.

When you start looking in creation mythologies from indigenous peoples outside of that small core region, you get far more diversity in the way they see creation. Native American creation myths tend to focus on a cyclical view of creation (i.e., this is not the first Earth to be created), for example, and there's no clean delineation between good and evil or order and chaos.

<comment><USER9> Birth and renewal is another theme that is central in many religions. In Christianity of course, Christ dies and comes back renewed. In Hinduism reincarnation is a foundational belief.

This theme appears in literature as well: Harry Potter sacrifices himself to the Basilisk (a snake, the dragon of chaos, who lives in the underworld beneath the school) in the Chamber of Secrets and is renewed (born again) by the phoenix (which is itself a mythological symbol of death and rebirth) at the end of the second book.

The themes aren't always enacted as part of the creation myth, but are often still present, and there's meaning in the reality that they appear so often and so consistently throughout myth and literature.

That being said, I will admit that I don't know enough about the Native American creation myths to comment on the way they approach good/evil and order/chaos. I would be very surprised if these themes were nowhere to be found within their myths, though, because the idea of the heroic individual who brings order out of chaos and defeats evil seems to be a human universal.

</comment></comment></comment></comment><comment><USER4> > but arguably introduced to mankind its first monotheistic faith.

As in no scholar in the discipline of Religion, Biblical Scholar or Theology would state this as anything but a real stretch by someone not well informed about world religions.

To say someone that we can't even give a date range of 500 years and we have so much other evidence of other monotheistic religions and the time frame for its development is put between 2000 and 4000 BCE. This is just poor academic research.

</comment><comment><USER11> Fun fact: Freddy Mercury was Zoroastrian

</comment><comment><USER12> And here I thought they would talk about objectivism...

</comment><comment><USER13> I recall reading somewhere that Judaism may have believed in existence of other gods...in genesis it says created in 'our' image, and I read some theories once that the sumerian god Anu might have become Elohim or the God of the jews...

I think the theory is that the god as well as the jews were outcasts and so that god made the jews his chosen people, and wrought mighty miracles, and convinced them that he was the only true god. or something along those lines. iirc Sumerian mythology in terms of time-line has the oldest texts known to man.

<comment><USER14> When I was a child growing up in the Southern Baptist Church system, I struggled with the paradox that the Christian God is supposedly the only god that exists, yet in the Old Testament that same god clearly told his followers that they should not worship "those other gods". I recall asking my pastor and other church leaders, even my own parents, about this paradox and I received non-answers, diversions, a lot of "gee, I don't know" or "you're right, that is strange" responses, and was even totally ignored once by a pastor who was visibly disturbed that a small child would dare ask a hard question.

Of course, as I got older and was exposed to the Internet I was able to research the history of religion and break out of the bubble. I learned that the Christianity of today is nothing whatsoever like early Christianity in its infancy just after Christ's death, and a large part of what is taught in traditional Protestant churches is wholly incompatible with his message. If you follow his commandment that we "love one another, that is the fulfillment of the Law", suddenly all of the _-isms_ have no place in a Christian's heart. Racism, sexism, homophobia, elitism, all violate the creed of "love your neighbor". Yet the most racist, sexist, phobic people I've ever met identify as Christians; yet another paradox to ponder.

<comment><USER7> > not worship "those other gods"

there are plenty of texts discussing 'false gods' as well -

e.g. put all together: there is 1 'true god', the others are 'false gods', and they should not be worshipped.

This base theology is very straightforward and consistent throughout the hebraic scriptures, and also in the NT if you view from the various premises of jesus messiahood in the gospels/epistles.

> what is taught in traditional Protestant churches

... Was invented ~500 years ago, and (imho) in reaction to other theological (RC) and sociological shifts (embryonic capitalism), and so this is not at all surprising...

> "homophobia"

[https://en.wikipedia.org/wiki/Homosexuality_in_the_New_Testa...](https://en.wikipedia.org/wiki/Homosexuality_in_the_New_Testament#Homosexuality_in_the_Pauline_epistles)

Dangerous words here, but disagreement with homosexuality is only _automatically_ a "phobia" if one presumes disagreement to be 'denial' of a 'reality' out of a 'fear'; if one is ambivalent on this 'truth', there can be 'phobic' people and those that simply disagree.

Either way, quite clear from the canonical texts that sexual purity (of all stripes - including heterosexual married couples) and ascetical purity in general were part of "early Christianity in its infancy just after Christ's death".. I will certainly agree however that what attitudes one takes towards adopting this (humility vs pride), is another matter and quite often many believers fall short.

Any doctrine can be abused to suit the ego gratification of its adherent -

Plenty of rabid and non-neighbor loving athiests, LGBT activists, libre software coders, etc as well..

Conversely, broad statements such as 'love thy neighbor' can be twisted to mean 'view anything as valid no matter what it says'..

it is in subtlety where the distinctions are found..

</comment></comment></comment><comment><USER15> I wouldn't be surprised if Zoroastrian Parsis had the highest IQ of any group, even though I have no data to confirm that. Higher than Quakers, Ashkenazim, Episcopalians and even Unitarians.

<comment><USER16> They are also good at arm-wrestling [https://youtu.be/1jyyBkohi3Y?t=12](https://youtu.be/1jyyBkohi3Y?t=12)

</comment></comment><comment><USER17> I wouldn't call Zoroastrianism an "obscure" religion at all. The term really doesn't fit.

Zoroastrianism was a major religion and the religion of one of the worlds major empires years ago.

True it's declined and doesn't have many adherents today but the word "obscure" just doesn't fit.

</comment><comment><USER18> My knowledge of Zoroastrianism came solely from Paradox Interactive games (Europa Universalis 4 and Crusader Kings 2)

</comment><comment><USER19> 1000-1500 bc,isnt judiasm ~4000bc?</comment>


Giant Squid, Elusive Creature of the Deep, Gets a Vivid Close-Up - <AUTHOR> http://www.nytimes.com/2015/12/30/science/giant-squid-video-japan.html <comment> rm_-rf_slash I was recently at a museum in Adelaide, Australia, which featured a scale giant squid exhibit. Story goes the museum cleared out a shaft for a new elevator but apparently the British manufacturers made a sizing mistake and an entirely new shaft and elevator had to be made, the question being what to do with the old one. Apparently a friend of the museum just happened to have a giant squid model on hand and donated it. The entire display stands at a length of four stories.

Imagine that, coming to the ground floor and seeing the ends of the longest tentacles. You walk up three stories and you still haven't even reached the full height. Then imagine literally running into one of those incredibly long tentacles at ocean depths far beyond the faintest traces of sunlight. Terrifying.

</comment><comment><USER2> >> They can be as big as a bus, or even bigger, and yet the elusive giant squid has hardly been spotted swimming alive in the ocean.

It's hard to read past such a false statement. A couple of their arms are perhaps longer than a small bus, but nowhere near "bigger". It isn't even the biggest squid (see the Colossal Squid).

Articles mentioning footage of live specimens should also note that they are almost universally ill, near death when filmed. They do not belong near the surface. Despite their size, these are short-lived and delicate animals prone to injury.

Also, live specimens have been captured as far back as 2002. So all this talk of "first time" footage is a little disingenuous. Researchers had them swimming in tanks aboard ship more than a decade ago.

[https://web.archive.org/web/20110710133329/http://animal.dis...](https://web.archive.org/web/20110710133329/http://animal.discovery.com/news/briefs/200202/giantsquid.html)

<comment><USER3> There is a large range of bus sizes, a 40' giant squid would look larger than a small bus ex: [https://en.wikipedia.org/wiki/School_bus#/media/File:Blue_Bi...](https://en.wikipedia.org/wiki/School_bus#/media/File:Blue_Bird_Number_1_bus.jpg) or [https://en.wikipedia.org/wiki/Blue_Bird_Micro_Bird#/media/Fi...](https://en.wikipedia.org/wiki/Blue_Bird_Micro_Bird#/media/File:%2700-%2702_Ford_E-350_School_Bus.JPG). But smaller than an extra large 97 seat school bus.

<comment><USER4> I think the point is that 'bigger' implies that the squid is actually larger than a bus, not just longer in one dimension. By the logic of the article, I have a garden hose that's bigger than a bus.

<comment><USER3> In the water with legs akimbo, it's going to be longer, wider, and taller than a small bus. [http://www.animalstown.com/animals/s/squid/wallpapers/squid-...](http://www.animalstown.com/animals/s/squid/wallpapers/squid- wallpaper-4.jpg)

Sure, there would be a lot of space between the legs and it's still fairly light. But, visually in the water a 40+' squid going to look huge.

</comment></comment></comment></comment><comment><USER5> Beautiful! Things like this are one of the upsides of the proliferation of cheap cameras - rare sights that would previously go unreported or disbelieved can be easily captured. (Though it's not doing wonders for my holdout belief in Bigfoot.)

Science question here: what's the slit between the squid's mantle (upper body) and the eye? Is that an injury?

<comment><USER6> Nah, this slit is the only normal thing about this animal.

<comment><USER5> What isn't normal about it? (Aside from the fact that it's a nominally deep sea creature in a littoral zone in this instance.)

<comment><USER2> It is dying and/or much of its flesh is already dead. They should not be white. Even if healthy, those eyes are probably blind in such light. I doubt this animal is capable of reacting to much of anything.

<comment><USER7> AFAIK this statement is 100% wrong. The Architeuthis, while slow moving, looked totally healthy to the diver and bystanders that looked at it, as well as to this amateur teuthologist (look it up). It sprayed some ink and did exploratory movements with its tentacles that suggested it was confused rather than sick, and while docile, moved on its own throughout all the (five) different videos I saw. Almost certainly a juvenile, it is nonetheless in much warmer and lighter waters that where it lives, which would explain the constricted size of the eyes. The mottled colors are just one of many looks this awesome animal presents to the world, reflecting stress perhaps but not an indication of ill health at all.

<comment><USER6> Sandworm is right. This is obviously an agonizing squid.

</comment></comment></comment></comment></comment></comment><comment><USER8> First photos of a live specimen snapped in 2005 and only a few sightings since. It really reinforces that not all of nature has been discovered by humans and there is still much need for exploration.</comment>