Live data from Hacker News

Choose boring employees

sicpers.info

41–44 of 44 posts

Re: Choose boring employees

#41

Earlier quoted context omitted.

I built an private side project app that was in use at of the major brokers. 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 wil…

I think a key thing you're missing is that you're new to React/Redux. Of course you won't be as productive with something you're just starting to learn (rebuilding something multiple times is natural when you're still figuring it out, but that goes away). 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…

Flawed feedback. I trained myself in Elixir for a few weekends and once things started to click in my head (I was always an OOP / imperative programming guy so learning functional programming took me some trying) then I was able to do a mini-project that had real value... in 2 working days.

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.

Re: Choose boring employees

#42
post #39

Tech choices matter. The industry evolves and all of this experimentation in languages, frameworks, tooling, and libraries has led to real productivity gains. 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…

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

Switching from Ruby on Rails to Phoenix (Elixir) definitely made me at least 3 times more productive -- obviously not 10.

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?".

Re: Choose boring employees

#43
I think the more important thing here isn't to choose 'boring' employees or tech stacks, but to choose what's actually needed for your situation.

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.

Re: Choose boring employees

#44
post #8

If boring == profitable, sign me up!

Sadly, usually boring is just boring.

One thing I've noticed is that companies will use cool languages as a recruiting tactic. Then you get in the door and see it's all PHP and one team wrote one Clojure script. (Not picking on PHP here).
Post reply on HN