Today's Top Tech Skills - <AUTHOR> https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/ <comment><USER2> It remains weird and disturbing to me that "AWS" is treated as a skill. Not "cloud system management", but " _AWS_ ".

Edit: I do understand _why_ it can be lucrative to have expertise with a specific cloud provider. It's just the status quo of these services being their own unique silos that disturbs me: I would personally be wary of making "ability to effectively use Amazon's servers" a pillar of my career.

<comment><USER3> I am a mechanical engineer. Mechanical engineering jobs ask for SolidWorks/AutoCAD/CATIA/Creo/etc experience, not just computer-aided design; ANSYS/ABAQUS/NASTRAN/etc expertise, not just finite element method; Fluent/CFX/OpenFOAM/etc knowledge, not just computational fluid dynamics.

With the exception of OpenFOAM, all of these software are proprietary, largely non-interoperable, and expensive—like thousands to tens of thousands of dollars for the cheapest option with basic functionality kind of expensive; like I can never imagine opening my independent consultancy business because how expensive the basic tools are kind of expensive.

Outside of programming, this is the norm. The number of free and/or open- source tools available to a mechanical engineer or an electrical engineer are infinitesimally small and it is almost impossible to do a serious engineering project with only free tools.

Since this is quite lucrative for the companies making those tools, I can only imagine tech companies would be more than happy to lead us to a future where software engineering is similar in this regard to other engineering disciplines. Perhaps this is what happens when a field matures, and since software is maturing, it will become more and more like this as the time goes on.

<comment><USER4> >Outside of programming, this is the norm. The number of free and/or open- source tools available to a mechanical engineer or an electrical engineer are infinitesimally small and it is almost impossible to do a serious engineering project with only free tools.

>Since this is quite lucrative for the companies making those tools, I can only imagine tech companies would be more than happy to lead us to a future where software engineering is similar in this regard to other engineering disciplines. Perhaps this is what happens when a field matures, and since software is maturing, it will become more and more like this as the time goes on.

That's a really great insight. (Sr EE here.) I wonder sometimes about the fact that SW engineers are capable of making their own tools in a way that we are not. Do you think this helps to combat some of the super high pricing associated with their tooling?

For example: it'd be pretty hard for me as an EE to say "Fuck it! I'm fucking sick of Orcad! I'll just go write my own fucking Orcad!" (OK, well, easy to say. Hard to do. I've spent plenty of days cursing Orcad, but none building a suitable replacement.)

<comment><USER3> > I wonder sometimes about the fact that SW engineers are capable of making > their own tools in a way that we are not. Do you think this helps to combat > some of the super high pricing associated with their tooling?

I can only speculate, since I am not a software engineer, but I think part of maturing is things get more complex and making things more difficult and expensive. Thirty years ago, someone could say "Fuck it! I'm fucking sick of Unix! I'll just go write my own fucking operating system!" and actually do it. Today, operating systems are so complex and large that this is not feasible anymore. Maybe you can write your own AWS replacement today, but would you able to write a replacement for AWS of 2050 in 2050?

It it one of those things that I would be happy to be proven wrong about, but as of now, I am not super optimistic that the current state of freedom of software engineering tools would continue indefinitely.

<comment><USER5> I don't think it's about software getting more complex. It does become more complex, but you don't actually write more code or handle a more complex architecture, you just build it from more complex blocks. Those blocks are packaged so their own complexity is hidden from you.

And you can write software on you spare time, and distribute it. Like it was done for Linux, gcc, git, and many other open source software. The other reason we have free software is because many software companies write their own tools and distribute them as Open Source because those are just tools, not what makes them money.

AWS on the other hand, is not just software but it's infrastructure. It's servers that are running, maintained, etc. There are already Open Source alternatives to AWS, that you can install on your servers and maintain, but it's a very different experience from using the AWS tools on Amazon's servers.

</comment></comment></comment></comment></comment><comment><USER6> In Java I'm a big fan of using SQL directly versus ORM. To that end I highly recommend JOOQ. I library that allows for object oriented SQL. Its not ORM, so you still compose SQL, you just get a lot objects and methods to allow you to construct your SQL in an OO, and functional, programming type way.

It also is a DB first approach. Where you construct your DB schemas and tables first, then use JOOQ to create objects that match your DB schemas. These objects allow you to reference the tables and fields of your DB in an OO way. From that point of view it may seem like ORM, but you use SQL to interact with the your DB.

Two of the things I really about JOOQ is that you stay in-tuned to SQL, which as we all know is very powerful and popular. Second, your SQL can get constructed in a procedural way based on input. So you can added to based on , for example, if query param were provided.

The creator of JOOQ, Lucas, has done good videos out there comparing SQL to ORM. What's cool about those videos is he does not mention JOOQ, maybe at the end. The videos are just comparing ORM to SQL and makes the case for SQL being way more powerful than ORM.

<comment><USER7> With jOOQ you still don't write SQL, you write the DSL and still spend a lot of time looking up docs for how to write the query in the DSL, when all you really want is to write the SQL query without the ugliness of JDBC. To this end I highly recommend JDBI.

If the Java proposal for multi-line strings ever gets done it will make writing SQL queries a lot nicer.

<comment><USER6> Please note the DSL is a one-to-one mapping to SQL. So its still SQL, you just have to identify the correct method that maps to your SQL element.

<comment><USER8> Soooorta. It can actually translate between SQL dialects so it's a more like 1:10 mapping.

<comment><USER9> I like that line of thoughts. Given that we have a parser, too, it's more like a 27:27 mapping: [https://www.jooq.org/translate](https://www.jooq.org/translate)

<comment><USER8> You're here!

I asked you a bunch of questions and even filed a few issues a few months back.

You were incredibly patient and helpful as I tried to sort out the performance characteristics of the a few bulk insert approaches.

I want to publicly thank you again for all your help. You've set a uniquely high bar with all your work on and around jOOq.

<comment><USER9> Thanks for your nice words, I really appreciate it! :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I've always been frustrated by the promotion of this kind of list. Yes, it matters what the demand for a given skill is but that knowledge is virtually meaningless without _also_ having information about the supply side!

If 1,000,000 companies desire talent $foo which 2,000,000 workers have, it's not going to lead to as many opportunities or as much leverage as talent $bar that 300,000 companies desire but only 50,000 workers have.

<comment><USER11> There's also a question of skill liquidity: if there's a very low supply and a low demand - even though the demand might be multiples of the supply - it puts everyone in a tough place. The employee doesn't have the leverage they might hope for because finding a compatible employer is very hard.

<comment><USER10> Yeah, this is a huge, issue. Even in cases where there's high demand on all sides, the difficulty of evaluation, the difficulty of firing, etc lead to a lot of poor outcomes for employees and employers both.

</comment></comment></comment><comment><USER12> I've tried several times to switch the URL to [https://www.hiringlab.org/2019/11/19/today's-top-tech- skills...](https://www.hiringlab.org/2019/11/19/today's-top-tech-skills/), which is the source that this one is copying from, but our software insists on escaping the apostrophe to %27 and hiringlab.org won't unescape it, resulting in a 404. I don't think I've seen that before.

Edit: never mind, taking out the apostrophe works! URL changed from [https://spectrum.ieee.org/view-from-the-valley/at- work/tech-...](https://spectrum.ieee.org/view-from-the-valley/at-work/tech- careers/sql-java-top-list-of-most-indemand-tech-skills), which points to this.

<comment><USER13> The escape rules vary in small maddening ways and trying to figure out if your implementation is doing the right thing from specs will make you give up forum moderating and join the merchant marine, in the best case.

Fortunately, that's the sort of thing Google can afford so it's safest to just check what their RFC-compliant utility libraries do:

[https://guava.dev/releases/28.0-jre/api/docs/com/google/comm...](https://guava.dev/releases/28.0-jre/api/docs/com/google/common/net/UrlEscapers.html#urlPathSegmentEscaper--)

The apostrophe is not escaped in URI path segments.

<comment><USER12> Thanks; I've added non-apostrophe-escaping to our list.

</comment></comment></comment><comment><USER14> I got back into java recently and am appreciating how you can define an interface reference type super class then swap out the different data structure subclasses as their implementation. E.g. make a queue refer to either PriorityQueue or LinkedList. Or make a Map a HashMap or TreeMap. It kind of provides an "aha!" moment in deeper understanding of why there are so many Datastructures and why it actually matter to pick 1 over the other if in the end they are both implementing the same functionality. With python/js , yes those DS are still there but they are most of the time hidden for your convenience (which is great sometimes when you just wanna pump out some idea). The Accidental joy of Java (with its verbosity) is that by pushing the DS choice to time of reference setting, it makes me have to actually think about the choice more and what it would mean.

<comment><USER15> If you're looking to go lower (systems) level, or even if you're not, rust is worth checking out then too. It's the best experience I've had letting you require only the interface that does what you need, and it's also great at letting you make a type "from" something. e.g. you could require something be a HashMap, or merely that it can be converted `Into` a HashMap (a free action if it's already a HashMap).

<comment><USER16> Yep, sum and linear types are two of the biggest improvements of Rust over, say, C++. The third would probably be that it's a lot smaller than C++.

</comment></comment></comment><comment><USER17> Java is still undisputed in the enterprise. Node.js was a contender but lost steam. May be .net once it becomes truly platform neutral have a chance to take on Java. Until then most probably it will remain widely popular.

<comment><USER2> I figured that was mostly due to legacy code at this point; is it undisputed for new code too?

<comment><USER18> I can only speak from experience, but I know two large corporate entities that used Java and have over the years dropped it in favor of Go and websites.

Edit: i like how my first hand experience is disagreeable and should be hidden. This site gets STRANGE with facts that users just don't want to see.

<comment><USER19> Basically fad driven development.

<comment><USER20> "Comments should get more thoughtful and substantive, not less, as a topic gets more divisive."

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

Same for another comment of your:

"Yep. golang is one big appeal to authority fallacy at work." \- [https://news.ycombinator.com/item?id=21618006](https://news.ycombinator.com/item?id=21618006)

</comment></comment></comment></comment></comment><comment><USER21> I don't really understand the desire for skills to be in high demand.

Obviously, you want your skills to be in demand in _some capacity_.

But putting so much emphasis on whether some tech skill is a winner on a scoreboard can give people the wrong impression about other languages and technologies that appear to either be unpopular or dying. It's reassuring that Java and SQL are still in high demand after all these years, but newbies looking at these charts might make the assumption that they might as well not bother learning other things like Elixir, PHP, Rust, Ruby, etc., because they're not that popular, even though those jobs exist, will continue to exist, and pay well.

Also, it's disturbing that Scum is the 13th most demanded "skill".

<comment><USER22> This sounds horrible but maybe the people who would take these lists seriously are precisely the kinds of people who are careerist programmers. And they really just want the maximum value from their "investment" in learning programming.

In college I didn't learn Java at all because it didn't seem very fun. Python did and I learned that. Then Go came along which was easy to pick up. But once you know a general purpose language well, it doesn't take long to learn another one (maybe not the most performant code right away but that's what code reviews by peers are for).

<comment><USER23> Is there anything inherently wrong with that? They know where the butter for their bread comes from and make it work for them and reap from it.

As far as individual career choices go, seems like a winning move.

<comment><USER22> This is a good question. I think I don't want to work with careerists. Programming is a kind of labor that seems to have different properties than other kinds of labor, which can be quantified effectively and used to make accurate predictions. The sheer complexity of the field makes promising things a fools errand. The Agile manifesto is an acknowledgment of this unpredictability, and the approach they take is to quantify only the immediate next goals instead of predicting months ahead.

Careerists tend to like predictable slices of work which they can accomplish during work hours and go home and do whatever. Unfortunately, most high impact projects require a bit more involvement: not to give up all free time, but to be more flexible. A commitment to do the right thing (very easy to cut corners and ignore best practices) but to deliver on time.

Careerists tend to prioritize their quanta of work and how to get it done during work hours rather than focusing on getting it done well. They have to be coached into best practices. They need to be asked to meet deadlines, or disagree to deadlines if they feel it's inadequate. For these reasons, I personally do not like working with careerists.

</comment></comment></comment></comment><comment><USER24> I have always found this quite amusing that every company I have ever applied to for a job has SQL in required skills and yet not a single one of them has ever interviewed me on it.

<comment><USER25> It's because they have a database on the back end and you need to be able to write "SELECT * FROM [foo]" to get data.

I'd actually be really pissed if a company asked me to write a query like "count these orders by month in a single row" not because I couldn't do it but because I'm confident I'd screw up the syntax a couple of times.

I think they should ask more conceptual questions around set theory or storage structure, epsecially since they all want "SQL, SQL Server, Oracle, Postgres, etc". Nobody can stay on top of all the platform specifics, but someone who knows their stuff can answer the udnerlying problems.

</comment></comment><comment><USER26> Python's growth is staggering and I'm happy to see that it's challenging Java. There are certainly some use cases where Java has some big advantages but there are so many use cases where Python can get the job done with much less time and code. Plus I personally enjoy writing python more than Java.

I'm also curious where Go stacks up in this. In Stack Overflow's 2019 Survey [[https://insights.stackoverflow.com/survey/2019#technology](https://insights.stackoverflow.com/survey/2019#technology)] Go and Ruby were neck and neck at 8-9%. With Kubernetes and microservices getting so popular I'd expect Go's popularity to grow and maybe pass Ruby.

</comment><comment><USER27> Seems to me that Java is also still one of the most supplied tech skills. So this does not necessarily make it a market you want to be in. Good SQL skills don't tend to be that common though, but I think a lot of the demand is more for CRUD-level operations than for complex analytics or performance-sensitive stuff.

<comment><USER28> Most people don't know Java as well as they think they do.

<comment><USER29> Do they need that though? Will they be paid for that expert Java knowledge?

<comment><USER28> What kind of question is this? Expert engineers will be paid for that knowledge in any language. Tons of complex, high performance, and high scale applications are written in Java. Half of FAANG runs on Java. Contrary to what HN thinks the world doesn't only run on python, go, and rust.

<comment><USER27> _Half of FAANG runs on Java._

This is interesting and indeed not what I expected. Care to elaborate? I'm curious which components end up being built in Java.

</comment></comment></comment></comment></comment><comment><USER30> In the recent two or so years I was surprised to see how many people don't _really_ know about SQL. Sure they can write a simple insert and update query and maybe a join, assuming they can just ignore that there actually are different types of joins. But if you ask them about other _still fundamental_ knowledge like a _rough_ idea about what the different transaction isolation level are/mean/imply for you, they fail hard.

Realizing this allowed me to understand why:

1\. There is so many used ORM(ish) libraries which make it in practice harder to access the database for anything but trivial queries.

2\. NoSqlish databases seem to have became so successful even in application where non of there "benefits" (wrt. scalability and similar) matter and you would normally prefer to avoid some of there drawbacks (e.g. eventual consistency, no "system wide-ish" transaction, enforcement of correct schemata and some parts of data consistency). (Sure there are other reasons for there success, too. Like being fancy, modern or no clear requirements analysis and therefore no idea about scaleability requirements ...).

I mean if SQL and relational databases are for you just structs with a bit more basic types then JSON but which in turn are flat requiring annoying foreign key references and a bunch of ceremony around this with very little added benefits then yes it makes so much more sense to just use a nosql database and be done with.

(PS: Yes I'm aware that for certain use-cases the resulting databases can be very complex and hard to use, what I mean is that it's a skill you have to learn to use efficiently and a scarily large amount of people a came in contact with in the recent years not only don't have that skill but are not aware that, if they don't want to mess up larger databases they work on, they will have to learn that skill.)

<comment><USER31> My go to interview question to test basic SQL knowledge is use of "HAVING".

It's a surprisingly good filter.

EDIT: To clarify since this got more attention than I expected...I don't disqualify any candidate based on the answer to a single question. I just use that question to assess their actual SQL experience. If you've spent any amount time writing raw queries by hand for reports or just to pass through to a web service, you're going to have run into HAVING. It's a simple part of the basic SELECT syntax without needing to involve joins, subqueries, index optimizations or specific knowledge of database internals.

It's a fair question and the only way you wouldn't have run into it is from working purely with ORMs or NoSQL. There's a lot you can do without it, but it goes a long way in determining my ability to ask you to open up a query analyzer in different environments. It's also going to tell me a lot about the way you think about data problems and where you are going to gravitate for certain types of logic.

<comment><USER32> My experience with interviewers is that they all believe that their pet question is "a surprisingly good filter". Considering that there is rarely a data-driven approach to recruiting, usually this statement has a heavy confirmation bias.

Usually when you add data to the mix, you'll find that most questions are not significantly correlated with candidate success/failure once you condition on "ability to write any code at all".

<comment><USER33> Completely agree. Early in my career I had what I thought was "a suprisingly good filter" question I would ask candidates. For a couple years I did this. We hired one guy who had failed my question and then fired him a couple months later, which heavily reinforced my belief in the value of this question.

A couple years later I found the stack of resumes, some we hired, some we didn't. I realized that some of our best engineers had failed my question, and I had subsequently voted "no" (I was outvoted, fortunately, by my fellow panelists. Another reason I strongly advocate panel interviews but that's a separate discussion).

I soon realized that my question was good at filtering out people who didn't think like me, not at filtering out people who would make good engineers.

My takeaway was that everyone, especially me, could use a healthy dose of humility and self-skepticism. Not advocating swinging the pendulum into Impostor Syndrome (which I now struggle with sometimes), but somewhere in the middle is good and healthy IMHO.

</comment></comment></comment></comment><comment><USER34> The surprise is not that Java, C and C# are still ranked highly but that their share grew in the last 10 years.

It underscores the difference between (at least my) perception and the market reality.

<comment><USER35> I think that there is a misconception about how the industry looks. Many of us don't do web services and sites or anything even related to those such as adtech. We do boring software that runs in government basements, dishwashers, cars, intranets. We do huge desktop software with thousands of man years in them like cad packages. Probably most significantly we do boring integrations in ERP/CRM systems. Just Sharepoint alone is its own massive galaxy in the developer universe. The two branches "Enterprise" and "Government" are underrepresented in the discussions but not on the job market, I think that's where the perceived difference comes from.

Also we shouldn't forget C# has a resurgence on many fronts not least unity and as a very good nodejs replacement these days.

</comment></comment><comment><USER36> Good applications tend to get the database right first - since you can always re-write the mid-tier code relatively easily. It's pretty much essential to any developer.

Further it's a ridiculous superpower if you're not a developer - it's so empowering for anyone on the business side with questions to just go look in the db.

<comment><USER37> Weird, this is completely opposite to what a lot of people I've worked with have said. What do you think about having business logic in the DB layer too? I saw someone on another post recommending that which, again to the people I have worked with, is an antipattern.

<comment><USER29> Somewhat related quote:

Linus Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

IMO proper database design is extremely important. Code is fluid. You can replace it. Data is not that fluid, it's much harder to change it. Database should contain checks to ensure that bad data won't be saved.

I don't think that complete business logic should be in database. Keep data in database, keep your code in your application. Database is responsible for data storage and some data validation to prevent misbehaved apps storing obviously bad data. Application is responsible for everything else.

</comment></comment></comment><comment><USER38> I'm thinking about the future.

What skills will dominate the software market 10-20 years from now?

\- Big companies use C++ heavily, besides being the language for deep learning/GPU programming. Will Rust/Go replace it anytime soon?

\- Will React still dominate front end development?

\- What about Python and the data analysis ecosystem?

<comment><USER39> React might go away, but javascript/typescript will probably be a good bet for the next 10 years (who knows beyond that).

I'd like to think that people will come to their senses about Python and use sensible languages for ML + data once they relearn all the problems that software engineers learnt about it all that time ago (fast development != reliable/maintainable development, fast development != easily-scaled development with teams of 10+ etc)

<comment><USER40> >but javascript/typescript will probably be a good bet for the next 10 years

Honestly how is javascript (and thus typescript) ever going away at this point? I honestly mean _ever_. Like until the day I die. Almost the entire web is using it. Frameworks like React, Angular, Vue have made it so I basically don't care _that much_ about javascript. Most of my code is server-side and the client is largely handled by Angular as a framework so the amount of JS I have to write in my angular components is so minimal.

All that being said, I personally am not a fan of javascript.. at all. The learning curve to know what's going on is horrific in my opinion, and code is not meant to be written clearly but have a small footprint which is terrible. It's too flexible.. though typescript has solved 90% of that.

Even if something like Blazor completely transforms the web, it seems like there will ALWAYS be the case for streamlined simple sites that only need very simple javascript transformations..

Anyway- unfortunately I think javascript is here for the next billion years!

<comment><USER41> WebAssembly has some hope of changing how browsers are programmed, but you're probably right that JS will live on for many human generations as a legacy tech at least.

</comment></comment></comment></comment><comment><USER42> How come C# is on the rise 11% but .NET is on the down -15%?

Seems a bit odd to me

<comment><USER43> Well, it seems likely a lot of that is just measurement error, but there's a lot of arenas where you've got "not quite .NET" environments. I'm thinking Unity and Mono for iPhone/Android.

</comment></comment><comment><USER44> Never once in the last 20 years I went to indeed.com when I was looking for a job.

<comment><USER45> Sorry if I come across as stupid but where do you usually look? I'm only in my first role but I'm thinking to start trying to attract offers from elsewhere.

UK based if that matters on site recommendations

<comment><USER44> At first it was all through friends or connections. Then I found a job as the first engineer in a two person startup, posted on Craigslist (that was back in 2009). Eight years later that startup was sold for half a billion dollars. Today I would go directly to websites of companies I'm interested in, then find someone on LinkedIn who works there.

But - first you better make sure you're someone they would want to hire! Casually mentioning some cool project you put on Github, relevant to what they are doing, helps a lot in my experience.

<comment><USER46> How reproducible is this?

There are only so many companies that can make it to that level of success, and only so many pigeons to fill those holes.

</comment></comment></comment></comment><comment><USER47> Can't take Indeed seriously when they've omitted a major part of the industry which is:

\- mobile

[https://www.techrepublic.com/article/the-top-5-most-in- deman...](https://www.techrepublic.com/article/the-top-5-most-in-demand- developer-skills/)

[https://www.monster.com/career-advice/article/job-skill- mobi...](https://www.monster.com/career-advice/article/job-skill-mobile-app- development)

[https://insights.stackoverflow.com/survey/2019](https://insights.stackoverflow.com/survey/2019)

</comment><comment><USER48> > * SQL and Java are the top two tech skills employers want, according to > millions of US job postings on Indeed.com between 2014 and 2019.

> * Python is the third most common skill, posting strong growth driven partly > by data science jobs.

> * Amazon Web Services (AWS), at number six, has had even more spectacular > growth.

Source:

Indeed Tech Skills Explorer: Today's Top Tech Skills [https://www.hiringlab.org/2019/11/19/today's-top-tech- skills...](https://www.hiringlab.org/2019/11/19/today's-top-tech-skills/)

</comment><comment><USER49> There is demand from the average company treating "IT" as a cost center, and there is demand from top tech companies and startups which treat their software engineers as valuable. The latter are much less demanding of Java and SQL as required skills prior to joining, and I'd even say Go seems to be at least as popular as Java amongst top startups.

</comment><comment><USER50> If they are the most demanded skills in tech, then do practitioners command the highest compensation for those skills?

</comment><comment><USER51> I remember in years past these analyses would often have mention of Objective-C. Now I rarely see Objective-C or Swift mentioned at all. Is iOS development not as big as it used to be? Do people use react native or Xamarin or other cross-platform tool chains more?

</comment><comment><USER52> What about most compensated tech skill. Highly doubt SQL and Java rank highly there.

<comment><USER53> You think? A huge chunk of work at Google is Java.

<comment><USER54> The median pay might be quite low for Java, because there are also a hojillion poorly-paid enterprise wageslaves toiling away in the cubicle farms.

But the absolute number of people earning a lot (100k, 200k, whatever you think that is) might well be higher for Java than for anything else, because it's used in some significant big tech companies and in finance.

So, if you're of average ability, learning Java might not juice your pay much, but if you're highly talented, it might.

<comment><USER53> I also think that the people at that wage consider programming language choice as a means to an end rather than a core skill.

</comment></comment></comment></comment><comment><USER55> Curious how C# is up but .NET is down. Are they differentiating between .NET Core and .NET Framework?

</comment><comment><USER56> I don't understand why java wins?

despite:

\- the mess with ".equals()" and "==".

\- arrays don't accepts generics.

\- no (non-verbose) partial application

\- awfully verbose syntax that clutters the screen with unimportant things making important things hard to spot.

\- the confusing leaky abstraction with Integer and int.

<comment><USER57> Because there are programming languages people hate and programming languages people don't use.

</comment></comment><comment><USER58> Is mobile omitted or that it didn't make the top 20 or so

</comment><comment><USER59> the lack of PHP is surprising to me, but I guess there isn't that many PHP full time roles to fill?

<comment><USER60> Either it is specific to USA or the data is weird, [https://www.codingdojo.com/blog/the-7-most-in-demand- program...](https://www.codingdojo.com/blog/the-7-most-in-demand-programming- languages-of-2019) reports that in January (based on the same Indeed.com site) PHP is behind C#. PHP is powering >75% websites it just makes no sense to not even be in the Top20

<comment><USER61> It's because the complexity of those sites is low. My understanding is a large portion of that 75% is Wordpress sites. A very, very small portion of Wordpress sites do much development past a theme (many CSS/HTML) and installing some plugins.

If you have extensive Wordpress work, it's likely better to use a different starting point (and a different language).

</comment></comment></comment><comment><USER62> Java is the #1 programming language in the world, proven again!

</comment><comment><USER63> I have to wonder if Java would be in demand if not for Android?

<comment><USER64> Here are some companies that run much, if not most, of their backend on Java: Amazon, Apple, Google, Netflix and Twitter, not to mention pretty much every government, military, bank, hospital, airport, and utility company.

<comment><USER65> I thought Google was mostly C++, with Java being at best second to C++.</comment></comment></comment>


Did We Just Witness a Twitter Marriage Proposal? - <AUTHOR> http://mashable.com/2008/03/21/max-emily-twitter-proposal/ <comment><USER2> I used to joke with my friends who just got engaged about having a voicemail system "Press '1' to hear how he _proposed_..Press '2' to hear the tentative wedding details..Press '3' to leave a message'

I think it's a genuine proposal - and most of their wedding party/guests probably are already part of their twitter network. Nice one-to-many broadcast.</comment>


Jim Keller joins Intel - <AUTHOR> https://www.anandtech.com/show/12689/cpu-design-guru-jim-keller-joins-intel <comment><USER2> This guy is probably getting name-your-price offers. And good for him. He has been a key player in the turnarounds of many endeavors (AMD with K7/8 — the only time AMD significantly outperformed Intel and likely lead them to the Israeli team behind the core arch) and being part on the A4/A5 chips at Apple. Wow. Whoever has him on payroll has a huge leg up.</comment>


Ask HN: What to do about non-performing "founder" - <AUTHOR>

Posting under a throwaway account for obvious reasons.
We started up w/one cofounder accepting reduced equity for the promise of a salary after 3-4 months.
This cofounder had been very early stage employee in other startups with me.  However, now going in as a cofounder and having to accept no pay, was apparently a bridge too far.
His work was uncharacteristically sloppy and low output.  Clearly, he was sinking under the stress, almost from day one.
When it got to 3 months, almost to the day, he demanded that he had to start drawing a salary immediately.  We weren't making any money, or even ready for VC angel money, so my other partner (there are three of us), said we'd cover it.
Certainly one of the reasons we were not ready for looking for seed money was due to this co-founders non-performance.
When it came time for us to decide whether we would cover partner #3 another month, we declined, it really just wasn't worth it for the reduced output.
As a result, the paid cofounder essentially pushed himself back from the keyboard on the last day of the month.  He has been slightly helpful since then, but more along turning over stuff.
Amazingly enough, this has all been relatively amicable - I think my other partner and I both recognize that this guy just couldn't hold up under the strain.
But I'm also feeling a little abused now, as we sort of nursed/mollycoddled him along.  And we haven't signed off on incorporation docs yet, although they are all drawn up.
This is a stupid mess.  At one point, I want to really dock the guy's equity for non-performance.  OTOH, deal's a deal, and over time, assuming all goes well, he'll get increasingly diluted.
What would you guys do?  Yes, it was stupid not to have a performance/clawback provision in place, but the three of us had worked together before for several years, and there had never been a blip or complaint. <comment><USER2> Aargh-- first of all, why don't you have vesting in place? what were you thinking being irresponsible?

Solution given the circumstances-- if you have any doubts, he has to go. It would be best to have a frank conversation, explain your reasoning, and wrap things up cleanly with paperwork from your lawyers. Convince him that its better to part in a good way and find something that excites him. Give him a fair separation agreement, e.g. pro-rated stock for the 3 months etc. Get everything in writing, help him find a good next gig, and you'll salvage the relationship AND your company.

I would recommend giving some stock even if you had vesting and he hadn't hit his cliff for a few reasons:

(a) startups are a small world, no point in making enemies

(b) a little stock aligns long-term incentives. If he goes, and the company is successful because of that, he actually makes $$. When you're getting acquired he'll be there to help, because he will see a financial outcome. Giving no stock breeds hate and resentment.

(c) Startups are hard, grueling experiences, not everyone makes it. Its OK.

<comment><USER3> How does vesting work with two or three founders? Is there a commonly used period? Any links would be appreciated. I recall hearing a while back that there are some good books on how to set this stuff correctly. Didn't pay attention at the time :( Any recs?

<comment><USER2> Soak up every bit of venture hacks. Then read brad book called venture deals.

</comment></comment></comment><comment><USER4> Like you said, a deal's a deal. If you maintain a reputation as a reliable and honest person, it'll be much more valuable to you than the equity you could gain by going back on your word. The SV tech scene is a pretty small world, and a good reputation will help you grow your business in unexpected ways.

<comment><AUTHOR> I (and my other partner) do value reputation and overall I'm inclined to roll with this.

The only counterpoint is that the departing co-founder really didn't live up to his end of the bargain. Work was low output and quality and this isn't in retrospect. It was like the fellow started crumbling almost from day one & then, the obvious inadequacy of his efforts just sort of piled back on in feedback loop.

So while I feel sorry for the fellow, honestly I do, I also don't really in any way feel that he lived up to any spirit of his commitment to us and his non-performance has hurt us in material ways.

It sort of feels like a choice of either being a jerk or a patsy.

</comment></comment><comment><USER5> You do have to respect the terms of the deal. That being said, here's what I would do: 1) Fire him. Co-founders can be fired, and you and the other partner have majority vote. You wouldn't owe him any money because he hasn't worked since you stopped paying him.

2) Decide a fair company value and buy his equity stake. This guy is clearly a distraction and the best thing to do would be to completely cut dies and free up equity.

</comment><comment><USER6> Talk to a lawyer before you do anything. A few hundred bucks now will save you a lot of headache later. If you're going to be running a business, it's probably a good idea to get in touch with one anyways so you don't make any future mistakes when it comes to contracts.

</comment><comment><USER7> Do you have a vesting period? Pretty sure you didn't, but just making sure.

<comment><AUTHOR> No, we all came in under founders common stock. The partner in question took less equity as it was understood that he would have to draw something of a salary soon.

This wasn't because of lack of enthusiasm, just an economic reality for the guy.

But wow, as soon as we kicked off, it was like Jekyll/Hyde. And I've known/worked with this fellow for ~6 years, in fact I escorted him as first hire into his last gig where he did an outstanding job for several years.

<comment><USER8> When you say "we all came in under founders common stock", you mean that you WILL all have founders common stock once the incorporation papers are signed, yes? You said above that they weren't signed yet?

Founders should always have vesting. It is going to permanently screw up your company if this guy has some large percentage of the company and isn't a part of its success. Plus the rest of you should have vesting anyway in case another founder doesn't work out for whatever reason. Everyone should ALWAYS have vesting.

So my advice is that, if you haven't yet signed the papers, you should go back and put vesting on all of the founder's shares, including his, of course.

</comment></comment></comment><comment><USER9> Did you mention to him during the first 3 months that he was not performing?

If not, it seems to me like you might just be looking for an excuse not to pay him because you can not afford to.

</comment><comment><USER10> My suggestion is to sit down with him and work out a deal to help him leave the company for his own good. Let him leave with a compromised amount of equity and try to help him find a more stable job.

If he does not (whether he does or not, really) write your shareholder agreement to avoid situations like this.</comment>


Hyper: A terminal built on web technologies - <AUTHOR> https://hyper.is/ <comment><USER2> Built on electron. So, a full copy of Chrome is included in your terminal. Right?</comment>


What is Life? by Erwin Schrödinger (1944) [pdf] - <AUTHOR> http://www.whatislife.ie/downloads/What-is-Life.pdf <comment><USER2> It's remarkable how much this still rings true today.

The idea that we should try and understand life as a battle against the second law of thermodynamics has had a significant influence on many of today's great thinkers - such as Friston [1] and Dennett [2], as well as countless others.

[1] [https://royalsocietypublishing.org/doi/full/10.1098/rsif.201...](https://royalsocietypublishing.org/doi/full/10.1098/rsif.2013.0475)

[2] [https://www.youtube.com/watch?v=iJ1YxR8qNpY](https://www.youtube.com/watch?v=iJ1YxR8qNpY)

<comment><USER3> I've heard this called the "every refrigerator is a miracle" theory.

<comment><USER4> I don't see anything on this phrase on Google Search

</comment></comment></comment><comment><USER5> Wikipedia article: [https://en.wikipedia.org/wiki/What_Is_Life%3F](https://en.wikipedia.org/wiki/What_Is_Life%3F)

"In the book, Schrödinger introduced the idea of an "aperiodic crystal" that contained genetic information in its configuration of covalent chemical bonds."

Good to see it available (a classic; not so easy to lay hands on)

<comment><USER6> [https://archive.org/search.php?query=what%20is%20life%20schr...](https://archive.org/search.php?query=what%20is%20life%20schrödinger)

[http://libgen.io/search.php?req=what%20is%20life%20schröding...](http://libgen.io/search.php?req=what%20is%20life%20schrödinger)

</comment></comment><comment><USER7> Freeman Dyson reviews and extends "What is Life?" in his "Origins of Life," both a lecture[1] and a book.

[1] [http://inspirehep.net/record/1268726/files/978-4-431-77056-5...](http://inspirehep.net/record/1268726/files/978-4-431-77056-5_5.pdf)

</comment><comment><USER8> Our definition of life is very narrow, mostly self-referential. Life is everything. Just because we can't consciously communicate with something it doesn't mean it's not alive. Why wouldn't Earth be alive? How about the sun, the stars and the universe?

We love separating things by arbitrarily naming and defining them, but the universe is completely connected, we can't exist outside of it or disconnected from it. If anything, the only life that exists is the entire universe and we are just tiny tiny pieces of it with a very limited view and awareness of the whole. Pretty much the same way we are made up of billions of cells that likely have no way of perceiving the human body they are a part of (or "having a conversation" with it).

<comment><USER9> I think you may be familiar with the Global Brain hypothesis ([https://en.wikipedia.org/wiki/Global_brain](https://en.wikipedia.org/wiki/Global_brain)): what if the Earth is a large network system? And you know, the network is the computer...

Given the current empirical evidences we have, it's not particularity persuasive, but an extremely interesting imagination and proposal indeed.

<comment><USER10> What if even stars in a galaxy form a communicative network, communication meaning sending and reacting to signals on a purely physical basis which doesn't translate to a meaning to us yet. Gravity waves, electromagnetic signals, signals we are not aware of... I am not saying stars talk gossip but that there could be a signal exchange and a systemic reaction. We see it in practically all life forms on Earth and a in a way in the non-alive world as well when you look at the climate, for example.

I mean, when I speak I physically interact and transmit signals through air vibrations which we developed to both detect and interpret. Other perceptive "life" forms would have a hard time telling what we communicate about as well. Hell, we can barely if at all understand what other mammals communicate about despite their biophysical systems being incredibly similar to our own. Plants communicate with chemical signals and root/fungi networks.

Predicted pictures of the universe at large look eerily like the brain's structure as well.

<comment><USER11> Certainly everything with gravitational mass or electromagnetic energy communicates with others via the waves and particles of physics. The question is only in the complexity of these messages compared to biological and psychological processes.

</comment></comment></comment></comment><comment><USER12> I took a course on History of Science and I was pretty shocked to learn that Watson, Crick and Wilkins were deeply impacted by this book. That type of cross pollination between disciplines and generations of scientists is fascinating.

</comment><comment><USER13> I remember finding a first edition of this in my university library during undergrad after reading the likes of Watson/Crick describe it as fundamental in their path. What bowled me over was that each paragraph in that edition - and so very likely the ones they read as well - was marked with a section symbol (§), itself closely resembling a double helix. At the time it felt profound that their conclusion was likely implied by the circumstances of their beginning.

</comment><comment><USER14> A miserable pile of organic molecules. But enough talk...Have at you!

</comment><comment><USER15> What is life? A forkbomb implemented in hardware.

</comment><comment><USER16> Structure is opportunistic in the sense that it results from energy bleeding out from the big bang into other fields, not only quantum fields but things like position - thus we get large scale isotropy.

I followed Shrodinger's ethos to its limits and all I got was perfectly isotropic relativistic spacetime foam.

I suppose that's what our universe will eventually decay into - and then what happens is up to anyones interpretation (conformal cyclic cosmology or what have you..)

I need to implement gravity, some type of coupling that can prevent equipartition of states from happening so quickly.

In any case, nothing interesting happens in small universes by the process of evolution. Evolution requires a balance between specifity of search/selectivity and magnitude. Less specificity will require more brute force magnitude. Just like any search of a space or data struct. Silicon just doesn't have the magnitude that even a mole of molecules does. Not even in the same ballpark.

The source is up here and easily portable to platform other than Windows

[https://github.com/churchofthought/ScatterLife](https://github.com/churchofthought/ScatterLife)

I need to update the video - the video is before I added a projection matrix to fix the hexagonal skew.

Another framework but using complex valued cells: [https://github.com/churchofthought/HexagonalComplexAutomata](https://github.com/churchofthought/HexagonalComplexAutomata)</comment>


In The Moment — This Happened to Me - <AUTHOR> https://medium.com/this-happened-to-me/ea95477e9d1b <comment><USER2> Had a similar CPR experience near my home in London: [http://blog.jgc.org/2010/10/you-never-think-youll-have-to- do...](http://blog.jgc.org/2010/10/you-never-think-youll-have-to-do-cpr.html)

Makes you realize how fragile life can be.</comment>


Lessons Learned from Software Rewrites - <AUTHOR> http://alexmartins.me/2016/07/28/lessons-learned-from-software-rewrites.html <comment><USER2> I've been dealing with a corporate ERP system for some time now, and -- whether rewrite or refactor -- the biggest challenge has been that nobody is willing to assert how it _ought_ to work.

At best, it's "reverse engineer it, tell me what it does, and then I'll tell you what feature I'd like changed."

<comment><USER3> This is a pretty eternal problem in software development. I now think that it is our jobs as developers to properly identify how things should work.

We're often not experts in the domain we're working on, but by asking questions about a user's workflow on a more holistic level, we probably have more insight into what workflow would be the most productive from a systems standpoint.

Of course, this is a back-and-forth. Sometimes users aren't sure of what they want. And sometimes we're not sure of what is the "best" system for what the users want.

Instead of asking the user where the button should be, ask them when they press the button.

<comment><USER4> Behavioural driven development (BDD) encourages this process. The developers flesh out specific examples with the business people using readable language, and that becomes user acceptance criteria.

It's no panacea, but it helps because it tries to prevent the business people dictating tech specifics, which the developers take too literally.

For example, a business person says "when I press the submit button the results must be stored in MySQL". What they really mean is that whatever they entered into a form must be accessible later, but the developers now believe they must use MySQL and have submit buttons.

By focusing on the "When I complete the form with data x, when I look at the form again later, then I see data x" you've moved the conversation to the business requirements and away from the perceived technical requirements.

<comment><USER5> > Behavioural driven development (BDD)

[https://cucumber.io/](https://cucumber.io/)

is a particularly awesome idea for specifying behavior. really want to try it out for a project sometime: the idea is to write the spec in these domain- specific "gherkin" files.

i find it comparatively difficult to get get buy-in on collaborating on anything machine-readable, however, unless it's from people who are comfortable with general-purpose programming languages, anyway.

nonetheless, in an industry where it's fairly standard for designers to build in domain-specific languages, i don't think it's an unreasonable skill for product managers to consider acquiring.

any user experience stories from cucumber, etc. on rewrites or otherwise?

<comment><USER6> In my experience it's a joke. It's a way for devs to write executable document strings for the tests they also write.

Absolutely no business person who is responsible at the level BDD works (the head of marketing for example) ever ever ever writes a working BDD description or frankly bothers reading them.

Maybe just maybe they are useful intermediaries for Business analysts but most of those have been fired.

Fitnese tests have more traction but then this is just exposing your API for user tests

<comment><USER7> This matches my experience. I used to somewhat blame the business folks for being too lazy and/or pompous to bother with their side of the bargain, but I've come to think it's just generally a solution to the wrong problem. The hard part is correctly translating from what is asked for to what is implemented, and executable requirements don't have anything to say about that step. In cucumber, I can take any arbitrary Given / When / Then statement and implement it in any way, including ways that are completely wrong and (worse) ways that are subtly wrong. The translation code just becomes yet more code that may or may not be correct, and in my experience, it can be a lot of code. When you find yourself wanting to write unit tests for your acceptance test pseudo-english translation layer code, you're deep in a rabbit hole.

<comment><USER5> i think this (the parent post) is truth: i've had conversations a/b behavior specification where edge cases simply aren't taken into account. so the specification would say, for example

"it does this when anyone clicks a button."

whereas there's often some implicit question, like

"what happens when two people click the button at the same time?"

and that kind of concern -- where the logical implications of requirements -- is not always handled by top-down requirements management... i'm almost certain i saw a fowler article on "conversational" requirements management recently, and that made a lot of sense.

<comment><USER4> In general, BAs should not be writing the stories, but they should be able to read them together with the developers.

I find that it helps, but it doesn't solve the whole problem. The most useful bit is the stories with examples, as those are what are so often missing from specs.

The problem with edge cases is that they are infinite. If there's an edge case that's likely to happen (ideally based on evidence of past behaviour), then it can either be in the spec or just in functional tests.

I like to think that BDD is like writing the documentation first. Would you put the edge case in the documentation? If not, it probably isn't the BA's responsibility to decide what should happen, and it shouldn't have a Gherkin- style story.

But it's not a silver bullet. It's a tool that helps solve some problems on some projects in some teams. Usually, it helps in cases where the domain experts are not very technical and where the domain problem is a fairly simple set of business rules.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> When I hear about rewrites, I always think about this comment:

[https://news.ycombinator.com/item?id=11554288](https://news.ycombinator.com/item?id=11554288)

<comment><USER9> I expected some wisdom, but that comment basically says that a rewrite either isn't needed because programmers are already excellent in the first run, or the rewrite will end with a similar shit code in paraphrase, because programmers have learnt nothing. Also it takes time, which costs money...

<comment><USER10> This is probably going to sound weird, possibly cheesy, but cottonseed got something out of that post, possibly more than I intended to convey, so I hesitate to follow up for fear of taking that away.

What I think I was getting at then, and certainly believe now, is that some people grow with the code, learn from many of their mistakes, and do the long quiet job of expunging their worst errors as they go. Their code is the best proof that they could accomplish a rewrite, because it already is a rewrite. They just didn't need to stop the world to do it, or at least not all at once. Perhaps a month here and a couple weeks there.

For the rest of the time it has been like the Ship of Theseus. All of the parts are new, and yet it is the same ship.

Meanwhile the rewrite guys are continuing with their mess and hoping they get a do-over, putting off things hoping for Some Day. And on that magical day, all of the bad habits of the entire team (management included) will correct themselves overnight.

Bad habits are too hard to break. The best of us know that you don't abstain from bad habits, you crowd them out with new, better ones. But that takes time, practice and determination.

If you want to condense it down to nothing new under the sun, that's fair, and I would offer that I wanted to believe the rewrite folks were onto something, but at the end of the day, breaking down the problems and using relentless refactoring seems to be the only thing that works, without changing the definition of success to achieve victory.

<comment><USER11> Additionally, as time passes you get new people working on the system that does not understand it as well as the original designers/developers, simply because they already have the system and their knowledge becomes pigeon holed inside of it. They don't have the original scope.

And then to top it off; if you did rewrite the system you not only need to reverse engineer N years of code, but also N years of bug fixes and random miscellaneous snippets that made it into the system and that no one who still works at the company understands the purpose of any longer.

</comment></comment></comment></comment><comment><USER12> Sometimes a better approach is to wrap the system you want to deprecate rather than have a parallel implementation. First, because you might not fully comprehend the current implementation to replicate it. Second, because in real life often there's not enough time, budget and coordination between teams to migrate old clients.

Since their main requirement was having a REST API for new clients, and apparently the old implementation worked fine, they could have implemented a EJB -> HTTP layer on top, and have new features talk straight to the DB. Eventually, they replicate all the features talking straight to the DB (w/ the added benefit they can test against the codepath going thru the old system). Finally, death by phagocytosis.

<comment><USER13> I think the problem was, that they had to implement new features for the clients only supporting the old version, too. At this point you are left with a HTTP wrapper around your old software, which does not qualify as a rewrite.

<comment><USER14> Well, yeah.

It sounded like an HTTP wrapper is all they actually needed. Or in fact any well specified wire protocol with lots of implementations. It could have been protocol buffers over raw sockets also.

</comment></comment></comment><comment><USER15> Strangler pattern FTW, well that and never have two systems share the same database. Always have one source of truth.

<comment><USER16> Could be worse. Imagine a situation where you have to work with an old Java code base, where there is a lot work arounds that had sense ten years ago but not any more, and you are using obsolete library versions like Hibernate 2. Add that you can find similar functionality made on totally different ways. Add that you can find abuse of some programming patterns. Add that you have your own XML based framework where you end doing XML based programming, and not sane way of debugging it except doing the equivalent of debug with "print("CACA"); return -1". Add that for some operations, the java code must do the same stuff that does a heavy client wrote on Visual Basic 6 that works directly against the same database. Finally add that the database design isn't the best (BNF form ? What are you talking? )and that you are stuck on using a internal tool that does the same thing that Liquid base, but worse, and it's based on some old abandoned Apache libs that no body knows well how are working or how we modify. At least, we know that we have a problem and where are trying to fix it.

And this is my diary work.

PD: I have a friend that lives on a worse situation, where they have an application based on Java 1.5 applets, with bad or not existent documentation, and nobody knows how works internally.

<comment><USER17> Are you also Brazilian like the OA? I ask because I know diário means daily in portuguese, but in English "diary" means a personal journal and doesn't make sense in this context.

<comment><USER16> Spanish. Thanks! I should wrote "daily", not ?

<comment><USER18> Yes, indeed!

</comment></comment></comment></comment></comment><comment><USER19> In my opinion, asking for "removing unused features" is one of the consequences of full rewrites. Also, a reason for having to maintain "dual systems" for years. It is not infrequent having "dual systems" and having to deprecate the "new", just because after e.g. 10 years you can not get rid of the old, or even worse: the "new" performing worse than the old (e.g. old simple centralized system working much faster on new hardware vs "new" pseudo decentralized mess that can not scale as good because inter-node communication overhead).

BTW, every time I read Martin Fowler quoted in a post as full rewrite justification for the "faith jump", I get scared.

I don't know why the poster didn't implemented the new API, using it for the new features, and eventually, rewrite old API commands (one by one, not all at once) calling the new API, so in the end, new API would remain, and old API would be just some wrapped calls to the new API.

<comment><AUTHOR> That was exactly our approach, for the old HTTP API, we kept the same contracts (URIs, response body, etc.) For the EJB one, as only one remaining client was using it, we deprioritized that, but we were going to pick the features they were using, and make the Java client point to the new API implementation, also keeping the same contract.

</comment></comment><comment><USER20> Joel Spolsky has a very nice writeup about the subject, "Things You Should Never Do, part 1":

[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

<comment><USER21> From the guy who had a new language invented instead of re-writing something...

<comment><USER10> I think Joel's articles were probably best when they convinced you of something you knew but hadn't articulated yet. If you aren't there yet I don't know that he always delivers.

And if he's selling an idea you've already abandoned, he can leave you flat for sure. His strength is in introductions, not reconciliations,

</comment></comment></comment><comment><USER22> But the siren song of the from-scratch rewrite is so difficult to resist.

<comment><USER23> I think of this as a saner version of the from-scratch rewrite, personally.

</comment></comment><comment><USER5> it's difficult to get a picture of all the nuances of this project, of course, from any quick read.. one thing that the article left me wondering a/b is the outline of "the new stack" which is "agnostic to any programming language".

i mean, i'm not the biggest Java fan, but it's alright, and there are some pretty good RESTful frameworks

[https://www.playframework.com/](https://www.playframework.com/)

while the strangler application (always a fowler link, always, in these types of articles) makes a ton of sense for making sanity out of incoming requests, i wonder if some effort could have been &/or was saved _behind_ the transport layer by reusing (possibly with refactor) the existing Java implementation?

whether doing so would make sense would be really situation dependent, of course, and an "outside" perspective from a quick article isn't going to have enough information to say anything conclusive. the (lazy) feel is that reuse is better than duplication of effort.

\</comment><comment></comment><comment>

aaaaanyway, super-good article. this is of of the kinds of things that's important to think about as a workaday web dev.

<comment><AUTHOR> Hey, thanks for your reply. Your line of thought is very similar to what we had. We considered refactoring the existing Java implementation. It used a really old Jersey version, with too many overengineered customizations tightened to that version. We tried to upgrade it and get rid of some of those customizations, but the system was so fragile that other parts of the system stopped working, which made that a really difficult road to drive. We wanted to simplify the design. We chose Scala and Finagle for the new stack.

</comment></comment><comment><USER24> > So once a functionality was implemented on the new stack, with all > characterization tests passing, all we needed to do was to tell the router > to use this new implementation, instead of the old one, and everyone > consuming this endpoint would be automatically using the new implementation!

How would that work without also migrating the database and while keeping the databases of the old and new implementations in perfect sync?

<comment><USER25> Migrate the DB in a backwards compatible way. So both version n and n-1 can use it. The next update (n+1) can then remove support for n-1.

</comment></comment><comment><USER26> This isn't a rewrite in the traditional "big bang" sense of a rewrite but normal software evolution and maintenance.

Anyway sounds like their approach was quite reasonable, just a bad title for the blog entry.

<comment><AUTHOR> It's an incremental rewrite. Rewrite one feature, switch everyone to use it, then destroy the old implementation. Do the same for all other features.

</comment></comment><comment><USER27> to grasp how bad that system agree, globo is Brazilian fox news. and only got on the web 10 yrs ago... and they're already on version 4

</comment><comment><USER28> Great article! It's interesting though, how did you convince management to remove features no one was using?

<comment><USER29> If no one was using them why do you need to convince management?

<comment><USER28> Because management decisions ain't always driven by logic.

The simplest reason may be attachment to the feature--the feature is of no use but the person who's invented it is scared by the possibility of removing it.</comment></comment></comment>


What sort of people should there be? - <AUTHOR> https://medium.com/@notionparallax/digitising-what-sort-of-people-should-there-be-aa416e8bbca6#.7soh9rf53 <comment><AUTHOR> I'm Digitising Jonathan Glover's book, What Sort of People Should There Be?

It's some early philosophy of what it would mean to live entirely in VR, how designer babies should work, all the cool stuff that was purely academic when it was written, but is pretty close to real now!

The book is here: [http://notionparallax.github.io/people/](http://notionparallax.github.io/people/)

and if you spot something that needs attention, the repo is here: [https://github.com/notionparallax/people](https://github.com/notionparallax/people)

PRs very welcome!</comment>


How to use interfaces in Go (2012) - <AUTHOR> http://jordanorelli.com/post/32665860244/how-to-use-interfaces-in-go <comment><USER2> When navigating unfamiliar Go codebases, it's hard to know which types fulfill an interface. Say you have a function that takes an Animal; how do you figure out what to call it with?

Or to give a concrete example, say you want to do formatted output to stderr. How is one supposed to determine that os.Stderr is something that can be passed to fmt.Fprintf? Is there a better way than manually comparing method signatures?

<comment><USER3> Use the Go oracle with an "implements" query.

<comment><USER4> So beside familiarizing the language syntax, I need to be aware of a set of unofficial tools and plugins, which are likely going to change in the next couple months, to be able to read the code.

<comment><USER5> It's an official tool. Also, most interfaces are very small (one to two methods) so it's pretty easy to figure out. I read/write a decent amount of Go every day and it's not often that I'm asking myself "what implements this interface?".

</comment></comment></comment></comment><comment><USER6> > type JavaProgrammer struct { > }

> func (j JavaProgrammer) Speak() string { > return "Design patterns!" > }

 _shrug_ At least our language designers trusted our intelligence enough to implement generics.

<comment><USER7> > shrug At least our language designers trusted our intelligence enough to > implement generics.

Trusted you so much that they even tripped on co/contravariance to add to the challenge :p

</comment></comment><comment><USER8> Read this when I was first getting into Go; super helpful and a fun(ish) read for people curious about the language

</comment><comment><USER9> Interesting. For pointers and interfaces, in this sample [http://play.golang.org/p/Lf8nn_pcYO](http://play.golang.org/p/Lf8nn_pcYO), `h3.Add2()` should fail as per OP said. I am sure, I am missing something important here. Please help.

<comment> ainar-g It shouldn't. The method you're calling takes a pointer receiver, and the Go Spec[1] says:

>A method call x.m() is valid if the method set of (the type of) x contains m and the argument list can be assigned to the parameter list of m. If x is addressable and &x's method set contains m, x.m() is shorthand for(&x).m()

In other words, if a type T no method M, it will look for M in *T's methods.

[1] [https://golang.org/ref/spec#Calls](https://golang.org/ref/spec#Calls)

</comment></comment><comment><USER10> The article is a pretty good intro to how to use interfaces. I think some people, especially those not familiar with the language would benefit from reading such articles and learning how to write idiomatic Go code, rather than ask for features that would allow them to write idiomatic $LANGUAGE_THEY_LIKE code.

</comment><comment><USER11> Previously on HN:

[https://news.ycombinator.com/item?id=9320235](https://news.ycombinator.com/item?id=9320235)

The blog post is from 2012.

</comment><comment><USER12> > func main() {

> animals := []Animal{Dog{}, Cat{}, Llama{}, JavaProgrammer{}}

> for _, animal := range animals {

> fmt.Println(animal.Speak())

> }

> }

This makes my eyes hurt. In this modern age we still haven't learned to create easy to read languages?

<comment><USER13> Not sure I understand - what part of this is not _easy_ to read? It's quite familiar to read and make sense to any programmer who's had experience with any of the C-like languages.

<comment><USER14> Is this sarcasm? That code snippet doesn't look like any C-like language that I'm familiar with.

</comment></comment></comment><comment><USER15> I don't understand why you would share a three year old post explaining the basics of interfaces in Go.</comment>


Tile5, HTML5+JS lib for building maps, tiles, googlemaps style widgets - <AUTHOR> http://www.tile5.org/

<comment><USER2> Hey Guys,

Absolutely happy to answer any questions or listen to any suggestions you have for the library. I'm going to work on a short presentation outlining "Why Tile5" which goes into why I have built Tile5. Most people are probably rightly asking as to why the world needs another mapping API, and I certainly think I can answer that...

Cheers, Damon.

<comment><AUTHOR> hey damon,

i know this is a bit off topic, but is it allowed to use the 3rd party maps (bing, google, ...) without the watermark?

best, markus

ps: 3 thumbs up for the great work!</comment></comment>


As Economy Turns, Washington Looks Better - <AUTHOR> http://www.nytimes.com/2009/08/08/business/08leonhardt.html?hp

<comment><USER2> This is one of the fastest media turnarounds I've seen in a recession.

IIRC, the 2001 recession didn't end in the media until later 2004 and early 2005, with the sales of Flickr and Del.icio.us and the development of FaceBook and YouTube. I remember that I didn't even look for sumer internships in 2003 because I figured the market was so bad nobody would hire a mere intern, and about half the companies I approached in 2004 said "We liked your resume, but we're not hiring now." In 07 (after this had all ended), I talked with a fellow computer programmer at a fencing class, and found out he was making _half_ what I was because he had graduated into the sluggish job market of 04 instead of the growth market of 05.

In the 91 recession, I recall the media being very subdued and depressed right up until Netscape's IPO in 95.

I don't remember the 79-82 recession, but to hear my parents tell it, there was a widespread belief that America had permanently lost its technological edge, and things would _never_ get better. This perception didn't change until around 1984, and even through my childhood in the 80s, I remember recurrent fears that we'd lost our economic supremacy to the Japanese.

The only recession I can think of where people started proclaiming "We've turned the corner; happy days are here again" a mere year after it started was the Great Depression. If you read <http://newsfrom1930.blogspot.com/>, it sounds almost exactly like something you could read in the newspapers today.

That alone makes me suspicious of this recovery. The point of a recession is so you _stop doing what you're doing_ and find new uses for your labor and capital; that hasn't happened so far. In all the recessions above, that's what brought the country out of it: new markets opened up and absorbed all the workers that were laid off by the old ones. I haven't seen that yet (though there are some interesting developments in mobile and in the revival of hardware hacking); mostly we've seen government attempts to paper over the inefficiencies in old industries with taxpayer dollars.

<comment><USER3> The whole thing is laughable. Very little bad debt was defaulted--most of it is hidden on the fed's balance sheet or by mark-to-magic accounting. Banks are letting people live mortgage-free to avoid booking a loss. The CRE, Prime, option ARM, and ARM problems are just getting started. And then there's this:

[http://www2.standardandpoors.com/spf/xls/index/SP500EPSEST.X...](http://www2.standardandpoors.com/spf/xls/index/SP500EPSEST.XLS)

H-50: A PE ratio of 116. This quarter is 118 so far. (!!!) Anything over 20 has been traditionally considered bearish. What do the people in-the-know think about this?

[http://www.zerohedge.com/article/las-weeks-insiders- transact...](http://www.zerohedge.com/article/las-weeks-insiders- transactions-5-buys-134-million-145-sells-1-billion)

<comment><USER2> Couple comments on those metrics:

1.) The value of a stock's supposed to reflect its earnings over all future time, not just current earnings. That's why stocks don't instantly fall to 0 when a company has a bad quarter. Earnings are at a low point now; a P/E of 118 implies that investors think they will get better soon. Whether they're right remains to be seen.

2.) Insider selling itself doesn't mean much. Many directors and executives receive a large portion of their compensation in stock; they're _always_ selling, because that's how they get cash to spend. I'm curious how it stacks up to pre-crisis ratios though.

</comment></comment></comment><comment><USER4> same old story...people manage to keep advancing despite the yoke of heavy taxation, government takes credit for every inch plowed.

<comment><USER4> ..is 40%+ taxation not considered heavy? I consider it pretty heavy. taxation is especially harmful to the primary source of economic growth: new small businesses. the tax burden of hiring new employees is so strong (and so risky due to litigation resulting from contract dispute) you'd think the government liked unemployment.

<comment><USER5> You're probably being voted down because you provide little evidence for your claims. It is practically impossible to "logically deduce" the result of certain elements of the economy because it is dependent on so many variables.

Consider, for example, the resistance in a wire. One might logically argue that because the power dissipated instantaneously in a resistor is equal to I^2 * R, that a decrease in resistance R leads to lower power (and heat) dissipation. Of course, that would be wrong, as that same resistor relates current to resistance by V=IR. Now, one can see that by decreasing the resistance by a factor of x (R/x), one also increases the current by a factor of x (xI, at a constant voltage). Thus, when the original problem is solved again, P=(xI)^2 * (R/x), so the power dissipation is actually _increased_ by a factor of x.

The economy works in the same way. To argue that taxes cause a decrease in first order capital may be true and may be a logical conclusion. _However_ , logically deducing broad statements about the economy through that is a logical fallacy. The solution to this is data, not more reasoning. Remember, the variables you forget never appear in your equations.

<comment><USER4> I thought my claim was pretty conservative. All my experience with small businesses (2 just in my immediate family, friends with lots more) is that dealing with the administrative as well as straight up monetary demands of taxes actively prevents them from hiring as many people as they'd like to. it seems like common sense that if you wanted to encourage employment you'd have like a 3 month moratorium on new payroll taxes when getting new employees up and productive. considering that you're taking someone OFF unemployment and turning them into an active taxpayer...seems like a completely unadulterated win-win for the government...so why is there zero incentive?

<comment><USER5> I'm sorry but you've just done the exact same thing again. You've essentially said that the entire US tax structure is bad, while only providing anecdotal evidence for your claims.

You claim that common sense will produce certain economic results, however in most fields claims of "common sense" would be laughed away. Anyone who argued that we can know both the exact position and velocity of any particle would probably be regarded as having common sense less than 100 years ago. Unfortunately, common sense is not proof of any measurable claim.

In addition, you continue to ignore variables in favor of the ones you care about. Specifically, you argue that the savings would positively benefit very specific segments of funding and revenue for certain small businesses. Meanwhile, you completely ignore the effect that the taxes have on other variables, like infrastructure development. This is the same fallacy of Power that I proposed before.

<comment><USER4> I can't name a scenario in which decreased tax revenue for the government is a bad thing. the claim that government spending is better than private rests on the idea that the money in aggregate can be directed more efficiently. the support for this is...nothing. I tend to think extraordinary claims require extraordinary proof. so if you make an extraordinary claim: I need to take your money for your own good, you need extraordinary proof.

the burden of proof does not rest with me, my position is that in the absence of strong evidence you should leave people alone.

</comment></comment></comment></comment></comment></comment><comment><USER6> We're not done by a long shot. The next wave of mortgage resets -- option ARMs -- comes through late this year and next.

[http://www.businessweek.com/lifestyle/content/apr2009/bw2009...](http://www.businessweek.com/lifestyle/content/apr2009/bw20090416_103126.htm)

<comment><USER7> information that is already known is always already taken into account by the futures/stock market.

<comment><USER8> It is amazing to me that anyone still believes this after the last two years!

But I suppose that a little irrational optimism is good thing in tough times...

</comment></comment></comment><comment><USER8> And perhaps "Cash For Clunkers" will get credit?

But seriously, it seems like "success" in economic terms these day means "postponing the day of reckoning till your successor is in office" and failure means the opposite. By that token Greenspan succeeded but Bush II failed.

<comment><USER9> by "these day" I assume you mean for at least the last 30 or 40 years?

A common story... (copied from [http://www.wickedlocal.com/milford/news/lifestyle/columnists...](http://www.wickedlocal.com/milford/news/lifestyle/columnists/x135734224/MARIE- PARENTE-The-envelopes) )

A CEO was being honored at his retirement party. The toastmaster, his successor, called on him for parting remarks and advice. After delivering farewell comments, the outgoing CEO handed his successor two envelopes marked #1 and #2.

He said, "Place these envelopes in the top drawer of your desk. When you make your first big mistake, open the #1 envelope and follow the instructions. When you make your second big mistake, open the #2 envelope and likewise follow those instructions."

The new CEO was young, handsome and an accomplished public speaker. He and his family were featured in business magazines and were invited to speak throughout the business world at home and abroad. For the first few months, things seemed to go along smoothly in spite of the CEO's frequent criticisms of the company's founders, business practices and employee performances. The new CEO seemed to relish pointing out the company's mistakes and perceived weaknesses. One day, the new CEO committed a huge gaffe that headlined business newsletters and newspapers nationwide! He remembered the two envelopes given to him by his predecessor.

He rushed to his desk, seized the #1 envelope, tore it open and read it. The message was printed in bold black letters. "Blame your predecessor." Immediately, he convened a series of press conferences, blamed his predecessor and things seemed to calm down for a few months.

About three months later, he made another gaffe of greater significance than the first one. Before meeting with the board of directors, he opened his desk drawer and read the #2 letter. It stated, in bold, black letters, "Prepare two envelopes!"

<comment><USER8> _by "these day" I assume you mean for at least the last 30 or 40 years?_

I suppose so. But, despite the great difficulty in proving this scientifically and the great risks of this being a mere effect of nostalgia, I strongly believe that the intervals of attention are getting shorter.

<comment><USER9> I"m sure the attention intervals are getting shorter. Mainstream media is painful to watch. I only picked the period 30-40 years as I'm 40 years old and it seems our political system has been "passing the buck" through my life.

</comment></comment></comment></comment><comment><USER10> This is article is interesting, and could in the end be correct in its rosy assessment and its allocation of the credit.

However, I find it interesting that this article does not say a word about inflation, the creation of currency, or the increasing national debt and the intermediate to long term affects those will have.

</comment><comment><USER11> It ain't over till the fat lady sings.

The economy is basically a chaotic system that is impossible to predict. It's kind of like the weather: More than a few days out you just don't know since there are so many variables and feedback loops.

<comment><USER8> Uh, _that_ the housing bubble would end was absolutely predictable. It wasn't a matter of butterflies in the Himalaya perturbing the system. _When_ the housing would was hard to predict.

That poor policies result in problems is not unpredictable and so it's quite predictable that this "recovery" will end in grief. When it will end is a different matter but your analogy with the weather is misplaced</comment></comment>


Web server performance comparison - <AUTHOR> http://wiki.dreamhost.com/Web_Server_Performance_Comparison

<comment><USER2> I really liked they mention that although Apache is not as efficient at handling a large number of concurrent conections and uses more memory, it's still the preferred web server for a number of reasons. I would have liked to know which version of Apache and which MPM they used.

<comment><USER3> mpm_event can do wonders for memory use. Sad that it falls back to mpm_thread for ssl.</comment></comment>