Choose boring employees
sicpers.info
sicpers.info
10X developers may be rare...but I don't think it's so rare to see 10X productivity gains when it comes to tech stacks.
For example, a company who runs their own servers manually can see dramatic improvements in productivity and agility if they move to a newer tech stack and run on AWS or Heroku or some PaaS as an alternative.
Using JQuery may be the tried, true, and mature front end stack, but I've been able to rewrite front-end code in a different framework with less than 1/5th of the code to maintain.
To summarize, I think you should hire energized, motivated, continually educated employees that stay at the top of their game...not boring ones.
I think the point of the article, which was rather subtle actually, is that "top of their game" is best defined in more general terms than simply "skilled in the top random webby crap from from the last 18 months".
I've been able to rewrite front-end code in a different framework with less than 1/5th of the code to maintain.
And about 10,000x as many dependencies, not to mention (if not exactly a shit-ton) a considerable degree of implied bulk in the form of new abstractions ("transpiling") and random contextual crap (packaging, etc) to maintain as well. And the implied path-dependence (for the sake of temporary benefit that comes from adding X, Y and Z to the project... it's going to be that much harder to refactor and shift to something else). All for the sake of a simple autocomplete form, and maybe a popup or two.
Which is exactly what's so cool about "boring" developers -- they see not just the positive tradeoffs in using the shiny stuff ("1/5 as much code") but the negative tradeoffs ("So you mean that hot new AngularJS thing everyone was yelping about 3 years ago... suddenly isn't looking so hot anymore? How come?") as well.
Dependencies can sometimes be a pain in the ass to manage...but they are a huge net positive for productivity. When the choice is between downloading a battle-tested autocomplete package written and maintained by someone like PayPal (https://github.com/paypal/downshift) and rolling your own thing...it's a no brainer. You use the battle tested lib unless you have a very good reason to roll your own thing.
Some tools fade, some tools stand the test of time. AngularJS has been deprecated even by its own creators (who built a shiny new framework with the same name)...so that's a bad example.
And potential collaborators and colleagues, likewise. Just give me people who are solid in the better practices of whatever language they use (even if it's Java or vanilla C) -- and reasonably aware of the current landscape (even if they chose not to, or heaven forbid, the quotidian needs of the real, money-earning products they work on don't exactly make it feasible to adopt the latest and greatest tools or platforms) -- over the type of folks who instinctively cargo-cult nearly everything that's been trending in the last 18-24 months -- any day, please.
AngularJS has been deprecated even by its own creators... so that's a bad example.
But don't you remember -- AngularJS was (if you took certain people at their word) the absolute shit some 4-5 years ago (that's slang usage of "the shit", as in "something really, really good you just have to get into, man"). Whereas now it's... well somehow no one wants boast about using Angular anymore, do they?
That's why it's such a good example of what I'm talking about.
I built it in react redux, because I thought it would raise "my" value.
I've had to rebuild that shit more times than I care to admit. Imho for a small dev shop picking react is a stupid choice. For a small dev shop picking node in the backend is IMHO also a stupid choice. I could go on with the list, but I'm going to stop knowing that I will already have upset enough people.
We've basically recreated the PHP problem. For whomever doesn't remember, before the first decent php frameworks like codeigniter(let's not talk about stuff like laravel) pretty much everyone built their own framework. After a couple of years when zend started to get traction they would integrate components from there.
The main issue wasn't all the security issues or the usual PHP complaints you hear. The main was the same you have in the javascript community:
> No two projects are the same
If you have time and money to waste for people to constantly update your tooling fine. But I don't. Hell just keeping up to date with airbnbs linting style guide was a major PITA.
EDIT: no I don't think the constant rewrites of redux and react router components, async connect, history etc. can be blamed on someone not having "enough experience in react". there's even a plugin to do regression tests on dependency updates. paying 100k for glorified javascript plumber jobs is unacceptable to me.
That's not to say that everyone running Angular or Backbone or whatever should ditch their current stack and rebuild in React. But, a new dev shop would be wise to pick React, because most people who become experienced with it are very productive.
I didn't have to deal with dependencies for more than 10 seconds (not an exaggeration), I didn't have to transpile, I didn't have to include shims / polyfills, I didn't have to explicitly include 2-3 CLI "task runners", etc. weird crap from the JS ecosystem that everybody in there thinks is normal for some reason.
You can't just expect people to worship your tech stack and blame them for "not being experienced enough". Hell, if you put enough labor, you can get solid experience on a custom-tailored banking system written in COBOL, or custom-programmed FPGA CPU units. You can become an expert manual tailor, too. But that's not the point.
IMO the point is -- are you able to immerse yourself in the tech stack you're proclaiming and be useful in business terms no more than 1-2 weeks later? If no, then your stack isn't worth investing into, especially after your stack is known to change trends as if it's some kind of a glamour fashion empire.
They can also see development and shipping of new features crash to a standstill if the move fails or, more commonly and even worse, they end up having to maintain and integrate 2 systems.
Tech stacks make a huge difference at the start, but once you're in maintenance mode documentation and tribal knowledge are way better uses of time than playing with new shiny.
I think those non-boring developers have good intentions, and certainly think of it in terms of staying on top of the industry, but I'm not sure they weigh all the factors in their choices. In particular, I think they tend to overestimate the benefit of switching technology while underestimating the cost to switch and the unknowns that come with a new technology. More than once I have heard a developer argue for doing a fair amount of work to switch to a new technology to gain what is in the end a relatively minor improvement.
In my experience, it's certainly possible that a new tech stack could dramatically increase productivity, but even more often it seems like the result in the long run is a heavy lift to embrace the new technology, followed by the discovery of unknown issues, followed by being underwhelmed by the improvement in the end product. I think it's worthwhile exploring new technologies as they come out, but on a strictly evaluation basis and with the understanding that switching to them should be a the result of a measured analysis rather than doing so just because they are new and exciting.
When did this happen? I'm certainly not 10 times more productive than I was 10 years ago. In terms of productivity I think the web is still catching up with what was state of the art productivity for desktop applications 10 years ago, and that was when I was writing in "low level" languages.
The ideal tech stack to me is one that is very efficient in terms of machine speed, memory usage and I/O utilization but it sacrifices some of its raw efficiency for human readability, ease of upgrade, less dependency problems, uniform tooling, debug-ability, strong community... etc. etc. problems we the programmers face daily.
To me, that is Elixir the language (and its web & API framework Phoenix, and its DB layer Ecto). For various outlier scenarios, to me that's also Golang and a lot of its non-web OSS libs and tools as well.
Ruby is a joy to code in (most of the times) but when your $50 VPS can't handle even 50 reqs/sec then you can see how that joy turns into bitterness when the boss comes telling you "WTF?".
Yep and we will be looking at the cutting edge always to see if there are things we can use to improve our stack/development process.
> Your product will be a year more developed.
Well that is how software development works.
> You will have a year more customers.
Yes and we will therefore have at least some stable income too!
> You’ll have a year more tech debt to pay off.
Yes, but because we have kept up to date in trends and technology the debt is significantly less than one might expect. Plus we aren't laser beams (i.e. very narrowly focused) which means we are able to manage three primary goals: fix bugs, improve/add features, and maintain/improve our stack.
This post was not great imo.
We're looking for a Synon 2/E expert right now. It's going about as well as you'd expect.
First pro tech job was at a small (8000 customer) ISP back in the 90s and our sysadmin was an AS/400 master. He'd show up once or twice a month, mostly just to check on things.
I think he made more from that company than the owner ever did.
It's not about being boring. It's about being pragmatic and focused on actually executing.
The simplest version would be something along the lines of - building a hardware startup? It probably doesn't make sense to build your company's ecomm site on top of React/Redux/etc. Rails works. Shopify works. They are boring options but they get the job done and get out of the way. Same company needs a blog? Don't roll your own, just find someone to manage a wordpress installation and be done with it.
Now that might very not be the case if your hardware has a substantial online component of course, but if your core product value is tied up in selling a hard good that doesn't need an app or a management interface of any kind then it doesn't really make sense to spend extra resources on a really cool website.
"Access to developer talent" is a reasonable factor in selecting a tech stack (e.g. there's a reason few use COBOL, etc.) But it's one of MANY factors.
Also, when many come here for the comments, or use an article about topic X purely as an excuse to discuss that topic in general (or see what their peers think), does the length of the source article matter much?
Fair point, I guess it doesn't.
If your site is a fancy web app where customers need to say, design their own website in the browser with a visual editor complete with Photoshop style image editing and what not, choose a tech stack that supports that as well as employees skilled with said stack.
That's a good use case for the latest Javascript framework you've been working with recently, along with cloud hosting on AWS or the likes.
On the other hand, if your site's just a content site (like say, a news blog or a basic forum), you really don't need all that fancy technology setup for it. Just create a nice basic frontend with HTML and CSS (with the odd line or two of Javascript where necessary), then use whatever your preferred scripting language and database is on the backend. Setting up a huge framework on AWS for this is like using a nuke to crack an egg.
And if you're looking for web hosting... well think hard about how popular your site is actually going to be first. Your tiny shop for local fishing supplies is not going to draw 50 million people a day, so you probably don't need a complex cloud hosting setup for it, nor a whole dedicated server/server farm.
Alas, a lot of people and companies nowadays seem less interested in choosing what they actually need so much as what sounds cool on their developers' CV/in online blog posts/on internet forums and Hacker News. So you get companies who are miles away from having any real customerbase whatsoever doing a boring job with technology better suited to Facebook and a couple of thousand a month cloud hosting bill.