Hacker News Reader

Comment by erikpukinskis | Hacker News Reader

Companies and coders will always push themselves to the absolute brink, where they no longer trust the code and the system is nearly unmaintainable.

Because every step towards that line has not just cash value, but exponential cash value if it’s a startup.

And by constantly pushing themselves into unfamiliar territory coders develop the most impressive possible resumes. They either have relevant experience or have experience in a tech even beyond what the company they are interviewing is using. That’s your best position to get hired.

It’s easy to write JavaScript you can trust. Heck, you can write a trustworthy web server in Visual Basic. Trustworthy code just isn’t worth much to 99% of the players involved.

View on HN

Sure, if you're going to dump your project in 6 months like a hot potato. Any coder that takes pride in their work knows that constantly piling on more tech debt to push thing out faster only slows down your project in the end. The only exception I can think to this is very early start ups, where if you don't get a product out in 6 months, then the project won't have a future to think about.

I think most companies do do this, on a rolling basis with different parts of the product.

Except by “dump every six months” it’s more like “after six months don’t add much to that anymore, unless we can dedicate a good three weeks to hacking it into place. And then dump the whole component in three years”.

Since your customer base and business requirements are likely to turn completely over in 3 years this makes some (perverse) sense for a startup.

This seems cynical and wrong. I've never written a line of code for the purpose of "resume padding." Trustworthy code is absolutely useful to a development team.

But writing that code is HARD. Training a growing team to write that code is hard. Banging out new features, on the other hand, is (at first) easy and seems more fun.

I don't think exact technologies per se are that important for "resume padding". Many companies do use relatively "old" technologies and don't care as long as the job gets done. Slack even uses PHP. Not to mention the big companies which might pay more attention to algorithm problems instead of the particular language you solve those problems in. Do the recruiters really think you are the one if your resume has all the newest hottest things written all over it?

Personally I learn new technologies if they are fun to learn and make my life as a dev easier. I'm not sure if anybody jumps on wagons just for the sake of it. For example I tried out Rust, Julia and Elixir, hated the first but liked the later two. I also tried Vue a bit but with Phoenix framework a lot of things can just be done with server-side rendering so I just dropped Vue in the project and felt totally fine with it.

Could you elaborate on this a bit; do you have any interesting real life examples of this mentality?

Sure.

I worked on the system which is now the customer admin for Square’s ecommerce platform they bought in Weebly.

We were all learning Vuex, while also trying to ship code. Across a half dozen pages we had a half dozen slightly different ways of addressing Vuex data. It wasn’t so much complexity that a professional coder couldn’t keep it straight in their head. But it was a trivial amount of complexity to fix. Two days work, maybe a week. Mostly variable naming.

But we chose to ship that feature because we wanted to prove to the company we could deliver. Now those coders will live with that choice for a log* time. New pages will use another slightly ad hoc scheme.

Eventually some architect will decide something like “Vuex is too conventional, we’ve got too much glue code, should we try switching to Redux or Vuedux?”

And the correct answer for the devs is: yes, it’s good for your resumes.

And (speculation) the engineering management will probably never swallow “we have to do three weeks of variable renaming and function moving to fix this now”. If they couldn’t swallow two days of cleanup in exchange for meeting an arbitrary internal target, they won’t swallow three weeks which probably pushes back a user-visible release.

* I meant to type long, but log time, pun intended

That sounds like no one actually designed or architect-ed the system, and everyone just went off and built things without an overarching plan. This is sadly somewhat common in software projects. This could be due to a variety of factors but to chalk every software project up to "resume padding" seems like a simplistic take.

Using your example but applied to other companies, I've seen the below, or some combination of all:

* Unskilled devs that have never used any of the new technologies and spent little time prepping beforehand.

* Management who demanded unrealistic deadlines or demanded devs skip design phase in favor of shipping faster.

* Lack of technical leadership, senior engineers are hard to come by at many large orgs and are often overworked or too busy to be everywhere at once.

* Cut throat career minded individuals that always jump ship to the next new thing.

In your case, it seems insane that you would be writing software with multiple teams or even multiple developers without some overarching plan. It shows a clear lack of technical leadership on the part of management and senior engineers.

I don't even think "jumping on the next new thing" is a particularly valid "career strategy". Many companies do use relatively "old" technologies and don't care as long as the job gets done. Slack even uses PHP. Not to mention the big companies which might pay more attention to algorithm problems instead of the particular language you solve those problems in. Do the recruiters really think you are the one if your resume has all the newest hottest things written all over it?

Personally I learn new technologies if they are fun to learn and make my life as a dev easier. That's it. I'm not sure if anybody jumps on wagons just for the sake of it. For example I tried out Rust, Julia and Elixir, hated the first but liked the later two. I also tried Vue a bit but with Phoenix framework a lot of things can just be done with server-side rendering so I just dropped Vue in the project and felt totally fine with it.

Reply on news.ycombinator.com