Hacker News new | ask | show | jobs
by archived22 2209 days ago
Job description these days become reflection of complexity in new age tech stack. Know C++/Java/Scala/Enter_Your_Lang_Here with python and React/Angular/Blah/Blah with Big Data Technologies - Hadoop, spark, etc. with Docker/K8 and with Azure/GCP/AWS.

It is time consuming process to become expert of one thing, requires couple of years of continuous focus.

I don't know How many people are actually expert of all these and how they are going to perform when some issue pop up in production. Try that judging it 30-to-60 minutes of interview.

2 comments

Almost no one. And you don't need an interview for that. As you said, it requires a few years of continuous focus. And most jobs won't give you that. So it's even more time.

And if a person with 5 years of experience sais he is an expert in a,b,c,d,e you don't need an interview do understand that this person doesn't even know what it takes to be an expert in one of these, because he obviously can't evaluate his skillset properly.

Nowadays you need very little to qualify to be "expert" or "senior".Sure there are exceptions, but in most cases, all you need is be able to use the technology. In most cases, people don't even understand how it works under the hood.

Just like with full-stack developers. Most of those whom I have seen know some front-end, some back end, and very basic database knowledge. And considering that in these cases both front-end and back-end are written in js mostly, "full-stack" here is a huge overstretch.

As lot of businesses do not reach that scale where architectural or design or quality issues may pop up, "full-stack" devs keep moving the wheel. I think that is good enough and good enough is OK.
I think this is largely representative of the real problem in web dev - the tech has changed, the complexity has grown, and yet the expectation that a web app is still something one person can build on their own using all the modern approaches hasn't changed.

You can still make something that works on your own, but not using all the new tech. You have to compromise somewhere. The notion of "full stack" devs is long gone. Making modern web apps is a team sport. You literally can't be an expert in everything you need to build a robust, scalable, fast, accessible web app anymore.

Another drawback of complex stack bites those people who have idea and money, but try to get product done through consultancy because they lack tech skill or does not have enough experience.

They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything i.e. Microservice Architecture and cloud and all and etc. since beginning. Resulting in unnecessary huge team and tech complexity. An idea or poc which could had been easily done and tested in market with small techstack/small team. No wonder lot of these products fail.

They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything..

Anecdotally, in my 20+ years of working for website and web app companies, I have never had a client who has even suggested a specific way of implementing an app. The closest has been when a client has asked for a tech proposal and had it sanity checked by a third party. These days I mostly work on "rescuing" apps that a client has had built by one company, found it hasn't gone well, and has come to the company I work for to make it work properly. All of the crazy tech stack implementations I've seen have come from developers who think they're clever, and never the client demanding something trendy.

It seems to me that simple devops decision making is becoming a forgotten skill outside of devops pros due to separation of concerns, whereas 15 years ago everyone knew how to install Linux or a BSD, set up required compilers and virtual environments, set up Apache or Nginx, set up a database along with database admin tools, etc.

Wasn’t any Ansible then, either, you had to write your own damn scripts.

The entire reason PHP grew so wildly in popularity was because hosting providers made it so you could just FTP a file with a .php extension to a server and it ran. Apache was the default web server for shared providers because you could do per account config like url rewriting by uploading a .htaccess file. Virtually no one was configuring their own servers or installing Linux on bare metal for websites.
That was a big reason, but I think another key choice was that the output format (HTML) and the input format (PHP) could be pretty close. If you were 15 and wanting to make a dynamic webpage, you'd look at an existing web page, copy it, and change one bit. PHP made that easy. The next change and the change after that were easy too.

In contrast, competing technologies started out with, "OK, learn computer science. Now learn how HTTP works. And then learn CGI. And some Unix. And then you can do 'Hello, World.'"

The funny part for me is that a lot of us in the latter camp didn't learn computers that way at all. We started out with BASIC:

    10 PRINT "Onion2K is cool!"
    20 GOTO 10
It had the same immediacy as PHP. The ease of making something happen was what drew us in. But somehow we forgot that. While also saying, "Here's something that will touch everybody on the planet. Let's all use it!"
Not just for websites, for other stuff.

How many people had rented servers for games? A lot. Now video game companies have turned game servers into a SaaS, whereas then they just released Linux server binaries. In the early 2000s there was a bare metal server rental company on every other street corner.

How many people had Linux/BSD network appliances? Also a lot. There was such a time when all you got from the cable or telco for your broadband service was a modem, and you had to roll your own router/switch. There were a multitude of run-from-a-floppy (or USB stick) BSD and Linux router distros back then.

Also, you're not correct on PHP. The entire reason PHP grew so wildly was because it was server side rendered, and both AOL and Microsoft intentionally hindered their browsers' javascript capabilities in lame attempts to monopolize the internet.

Sure you can, if you reject libraries and tools that were designed by large companies with a ton of specialization to serve the needs of those companies.

If you want to be effective as a small team, choose tools built for small teams. Rails is a great example.