[SirensOfTitan]

> I'd probably fire someone if I started to see `JSON.parse(...)`

I've had the privilege of working in organizations that consider mistakes to be the cornerstone of resilient systems. Because of that, comments like this scare me, even when intentionally hyperbolic. More so, if the product works well and is being maintained easily, why would you micromanage like that? Sounds like a minor conversation only worth having if the technical decision is having a real impact.

Thomas J. Watson:

> Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?

[dkersten]

You probably wouldn't want to work for somebody who fired people so easily anyway. This is one reason why I find it stupid when people defend companies or are super loyal to their employers: companies don't care about you and especially companies that fire on a whim without concern that they're fucking with somebodies life. Best to work somewhere that treats you like a human instead of as a cog.

[19ylram49]

To be honest, I understand the bit of backlash that I’ve received here and I think it’s well-deserved since I should’ve worded my statement better. Thank you for your comments.

You all are correct re firing someone over mistakes and seemingly trivial matters. I was mostly referring to software engineers who make impactful decisions without good reason and/or without properly assessing the trade-offs.

I think it’s fair to say that we all want performant software, but at the same time, if I have a software engineer on my team who can’t back their decisions with some form of data and/or understanding of the trade-offs, unless they’re at the junior level, they’re not the type of software engineer who I want on my team.

I said “performance reasons” precisely because, over and over and over again in my career, I’ve watched software engineers commit unreadable messes of code that were clearly premature optimizations and/or optimizations where the performance gains weren’t significant enough to justify the costs of the unreadable and hard-to-maintain code enabling them.

I once had a software engineer unexpectedly spend almost a week rewriting a critical part of a Java codebase using the JNI because he thought it’d “make it faster” — and it did — but then all types of new native code-related issues ensued that cost the company, including a major security vulnerability that was just impossible before. On top of that, it turned out that the performance gains that we noticed were mostly significant during the startup period of the JVM, so it really wasn’t worth it. And this was a very brilliant software engineer, but he was consistently making poor decisions like this. To be clear though, he wasn’t fired! I just use that story as a realistic example. (Part of me still thinks that he just wanted to learn/use the JNI and that project seemed like the perfect target. Lol.)

But yes, it’s more complex than simply firing individual contributors for sure and I regret wording my statement that way, but I hope you all can understand the real point that I’m making.

Edit: I’d like to point out that, in my anecdote above, in hindsight, if anything, I was probably the one who looked incompetent when the suits started asking the expected questions re the sudden set of new issues, because I did my best to shield that software engineer from them (or at least I’d like to think that I did). I know the feeling of messing up at that level and I knew that he was most likely already beating himself up, so I couldn’t just let him take the fall, or worse, throw him under the bus. These tend to be complex situations in real life!

[adimitrov]

> Part of me still thinks that he just wanted to learn/use the JNI and that project seemed like the perfect target. Lol.

As a dev who sometimes goes off chasing wind mills, that's 99% of the reason why I do it. I find something nice to tinker with, and when my brain goes "ooh, shiny" I stop giving a shit about anyone's bottom line.

To be fair, it usually turns out for the better for the project and its code base! But sometimes it doesn't, and I figure that's just the cost of doing business. Companies should be willing to take these kinds of informed risks in order to improve their employees' ability, and therefore the quality of their product. However, a lot of management only sees the short term gain, because long term gain isn't incentivized for them. They just wanna do well and get a promotion.

Well, guess what, it's the same for me. Except for me to do well, I have to be learning new things constantly. So tough poop, management, I'll be chasing my white whale every once in a while. Deal with it.

[19ylram49]

Lol. That’s the spirit!

[t1amat]

> Companies should be willing to take these kinds of informed risks in order to improve their employees' ability, and therefore the quality of their product.

Perhaps they should be willing, but your description of this distraction does not including informing the Company and allowing them to determine whether it’s a risk they are willing to accept. You decided for them because you didn’t want to receive the answer “no” in return. This isn’t right.

[cellularmitosis]

> "This isn’t right."

I'm afraid the morality of this situation isn't so black-and-white.

In industry, there is always a tension between production and research: cranking out widgets vs. getting better at cranking out widgets.

A dev who spends 100% of their time cranking out widgets is stagnating. That's actually not what your employer wants, despite the fact that their agile process seems to imply that ticket cranking shall be the whole of your focus.

If you ask employers if they expect you to improve your skills over time, they would absolutely say "yes". But if you ask for permission to chase a specific white whale, you will hear "no". Everyone agrees they should be saving for the future, but "not this paycheck".

Taking the naive moral approach here and spending 100% of your time on tickets is not "what's right". If anything, that's you being taken advantage of by your employer -- sacrificing the advancement of your career in the name of short-term sprint velocity gains. On top of that, stagnation is not what your employer really wants anyway.

(edit: the above excludes companies which have explicit "20% time").

[other_herbert]

I think i work in a similar manner to the gp.. It's transparent to the org... It's not I'll head down this path or investigate this _or_ get my work done.. It's an _and_ situation. Sometimes the rabbit trail is the best thing sometimes you just have to get the thing done... Either way it's still getting done

[adimitrov]

But it is an informed risk. I was hired to do work in 4 different languages, on the frontend and the backend, plus CSS and HTML. I get to weigh in on UX decisions, I get to design service infrastructure.

Was I born this way? No. I need this overhead, that's just part of being a dev (within reason).

If you require me to do lots of things, there's overhead. If you want a ticket drone for your Scrumfall projects, get a ticket drone.

[Gibbon1]

> And this was a very brilliant software engineer, but he was consistently making poor decisions like this.

That is something I've noticed. Brilliance doesn't go hand in hand with making prudent and wise decisions.

> I did my best to shield that software engineer from them

I've found rather painfully that you shouldn't shield guys like that when they go off on their own to make mistakes.

Other thing, you have a team of people that are familiar with how a codebase is put together and does things. And what sort of things go wrong. It's a bad idea to disrupt that 'just because' Goofus rewrites a module to use X fad. Great! Before there were five programmers who knew how that module worked and now there is one programmer who knows how that module works.

[munk-a]

Assuming you are managing a dev (either through a lead role, seniority, or as a manager) you absolutely should shield team members from direct demands from up that chain - that's what most of your job is... Assuming the employee was acting within the rules you've laid out then the you should shield them and consider adjusting your rules to prevent a repeat - if, to contrast, your company has some CI tooling setup and automatic deploys and reviews and whatnot - but then someone edits a file on production... that might be a fireable offense.

Additionally to contrast - if you're a co-worker and not a manager then you may need to examine your relationship (are you a mentor and thus secretly leading them or just a colleague). If a pure colleague makes a mistake you shouldn't stick your neck out too much - except to force your common manager to properly defend them.

Everyone who is fired should be fired by their manager and not anyone else in the org - that's how a team is strong and healthy.

And

Managers, in a healthy company, own the mistakes their subordinates make.

[Gibbon1]

> you absolutely should shield team members from direct demands from up that chain - that's what most of your job is

The other part of your job is keeping your manager informed about subordinates that are being problematic. Up and rewriting a critical piece of infrastructure 'because' is problematic.

[munk-a]

(I'm assuming that you mean that the other person is another subordinate to the same manager, rather than being someone subordinate to you)

It's a bit of a delicate balance. The golden rule is that Snitches get Stitches, but if someone is being unproductive with their time and your manager isn't aware of that fact then letting them know isn't a terrible idea. But it isn't your place to measure how your co-workers are accomplishing their tasks - assuming management isn't out to lunch then performance reviews should fall on their shoulders. Maybe your coworker cleared a rewrite with your manager and your manager was satisfied with the justification and decided that explaining the full reasoning would be a waste of time until the experimental phase was completed.

In theory good management should prevent you from feeling like you need to look over other people's shoulders, because that is their job. So if you are feeling that way you might want to talk to your manager about it, maybe they are bad at managing and are letting things slip through the cracks, maybe they find that allowing someone to experiment with a rewrite is worth the training time - it may be possible that you just need to talk it through with them and find more confidence in their management ability.

[wsc981]

> That is something I've noticed. Brilliance doesn't go hand in hand with making prudent and wise decisions.

Reminds me that John's Carmack wife told Carmack that she wouldn't allow him to bankrupt the family with his space hobby company (Armadillo Aerospace) :)

[dkersten]

My comment wasn’t meant against you personally (for all I know it was just for emphasis and not serious, and from your comment it seems like it), just against the attitude of firing people for small things, rather than, for example, teaching them to do better.

[bryanrasmussen]

I agree with everything you said, except that I'm not sure that JSON.parse all over the place is going to add any significant unreadability. I think most likely it would always look the same and be just as readable as object literals once the initial getting used to it period would be over with. Hell, I think it's a lot more readable than the use of !! which I consider an abomination, but everyone keeps doing that for developer speed = productivity purposes.

[saagarjha]

It might be more difficult to format a string literal.

[bryanrasmussen]

I'm supposing template literals take care of that. actually there might be advantages.

[mark-r]

I've found that the readability of fast code vs. slow code is often negligible - certainly it is in the specific example under discussion. I prefer to make a habit of using faster idioms in that case, so that when speed does matter I'm already covered. I don't consider that premature optimization.

[swish_bob]

Except it isn't, because most of your developers will be using an environment that includes syntax highlighting and probably some linting. Except within string literals.

Code inside string literals is less readable and more inclined to be wrong/buggy.

[mark-r]

I was arguing the general principle of not being afraid of premature optimization, not this particular example. You make good points.

[filoleg]

Eh, depends on the reasons for firing people easily.

Firing easily for honest errors is moronic, fully agreed, especially if the person is learning from them. My code changes caused more than one sev0 before, but never was I personally blamed for them, as it was always some bigger underlying system issue that wouldn't have allowed me to make those mistakes, if the systems were more robust (and I was a little bit more wise and not pushed "seemingly safe" changes outside of business hours). I learned a lot from those mistakes.

Firing easily for a long history of non-improvement and not meshing well with the team (underperforming, causing a lack of cohesion within the team, etc.) is good for the team, but in principle it is similar to the "good king" kind of approach, so it all relies on the "king" having a straight head.

P.S. My last paragraph does not imply "culture fit" or any superficial stuff like that as a good reason for firing, I meant more fundamental sort of issues, like refusing to listen to people, never even attempting to improve (given you have some hiccups, just like most of us), etc.

[dkersten]

I’m not against firing people if they are a bad fit, are incompetent or are toxic to the work environment. I’m against firing people for small things, not giving a chance to improve, firing on a whim or simply discarding people. Treat people like humans, but that doesn’t mean you can’t fire people who are a negative force on your business.

[hinkley]

I usually find the opposite. Firing someone for cause is interminable or outright impossible, unless they're breaking the law or embarrassing you in front of customers.

[Ensorceled]

I have only once fired for cause. Every other time, I’ve gone through the process, the PIP, and then terminated them according to their contract, usually with “more generous the legally or contractually required” severance. Let’s me sleep at night and has the nice side effect of keeping the peace with the remaining team.

[tyri_kai_psomi]

counterpoint: you are just as free to take the same liberty with your employer. You can drop them like a bad date, and take a job somewhere else.

additional counterpoint: part of your job as being a grown up responsible adult is your ability to manage and endure risk and loss, especially the risk of your job disappearing overnight. Outside of circumstances of extreme poverty, or extreme disability, in which our government has safety nets in place (let's save the debate of sufficiency for another time, the fact remains they are in place), losing your job should not "fuck up your life" moreso as be a temporary setback. This is especially true for this industry.

[TylerE]

Some of us can’t just lost our health insurance on a whim.

[pushpop]

Thankfully most other developed country’s healthcare system doesn’t penalise individuals quite so significantly as the broken system you Americans keep voting for.

I’m not saying the UK or other European counties have the perfect healthcare systems either but at least we aren’t tied to a job we don’t like because losing our company’s health scheme is too scary to consider.

[mamon]

If you're not paying for it with your money, then you have to pay with your time: public healthcare systems, like those in Europe are known for the long wait times for patients requiring surgery, or other costly procedures.

Also, traveling to the US for treatment is still a thing, because new, advanced treatments are developed and first implemented in the US, so all that money spent give you something in return.

[bcrosby95]

Unless you're rich and regularly wipe your ass with $xx,xxx bills, you end up spending your time in the US system too: getting your insurance and care provider to agree with what is covered, what isn't, and how much you have to pay.

Sometimes it takes almost a year to resolve.

BTW, even basic surgeries in the US can have a price tag of close to $100k. I've had to fight off more than one ridiculous bill like this in the last 5 years. If you're talking about medical tourism coming into the US, I can't imagine you're talking about anything but very well off people.

[pushpop]

> Also, traveling to the US for treatment is still a thing, because new, advanced treatments are developed and first implemented in the US, so all that money spent give you something in return.

It sounds like you’re saying America is the only country in the world developing new and advanced treatments and the only country people travel to for such surgery. Clearly that’s not even remotely true (and even if it were, which it isn’t, it still doesn’t justify just how badly broken your healthcare system is for domestic users).

[astrodust]

Whatever time I spend in the waiting room in Canada waiting for treatment, which is honestly less time than I wait for the cable company to show up to fix things, more than makes up for the fact that I spent literally zero time dealing with hospital bills.

Considering US hospital bills can easily be tens of thousands, a couple of hours wait at even $1000/hr. billable lost opportunity is still cheaper than the US alternative.

[amalcon]

In the US, you generally need to pay with both your money and your time. I've waited three months for an appointment with a specialist, had them only tell me to go to another specialist, and paid for the privilege.

[hvidgaard]

From the moment my GP refers me to a hospital for whatever reason they need to look at me, they have 8 days to respond, and must have a diagnosis within 30 days. Treatment is usually not long after and almost always proportional to the situation.

If a potential life threatening disease is suspected diagnosis and treatment must have begone after no more than 2 weeks. Most of the time it's a matter of days. If the public hospitals cannot do that I'm free to go to private hospitals without paying anything.

How is that waiting a very long time?

[tyri_kai_psomi]

You don't lose it on a whim. In the US, you can file for COBRA to extend your benefits, at which point that alots you plenty of time to apply for medicaid if the circumstances were extraordinary (why do I get this weird feeling most people on this forum just never have been poor or in this situation?).

That plus your emergency savings funds, should more than account to hold you over 6 months to find your next role. 5 years ago. I'll save my survivorship bias story for how I coped with this exact situation 5 years ago because I know everyone's situation is unique, but the lessons of growing up with 2 unemployed parents and living month to month not knowing if the bank was going to repossess our house have stayed with me I guess.

[dkersten]

Its an uneven power dynamic though. The employers typically hold many more cards than the employees.

[krferriter]

"typically"? I think you mean "always". This notion of it being an equal relationship in both directions is ridiculous.

[dkersten]

Well, there are those rare cases where the company relies on a person or small group to continue their business, but it’s not a typical situation.

[asdkhadsj]

Love the quote. Though, I have some people working with me who I would still struggle with that quote. There is an assumption in it that the employee grows from the experience.. yet, I face people who seemingly make an effort not to grow.

[ppeetteerr]

I would also micromanage this way. Developers leave, code remains. If your code base is full of `JSON.parse(...)` in a few years because of some developer who though "how clever to do this instead of object literals" it's not the author who has to live with their decision, it's the next code maintainer.

I see too many programmers being too clever and then leaving their clever code to become someone else's issue. My advice is be simple and make readable code. No one wants to maintain the clever code of another person.

[ergothus]

Firing instead of teaching when the person can learn isn't management.

The problem isnt that maintainble code isnt worth the effort, the problem is that firing people until someone matches your demands is not the most effective way to GET maintainable code.

[TeMPOraL]

Tough life that maintainer is going to have, seeing `JSON.parse(...)` being wrapped around object literals in code. This truly is going to cost them many man hours and lots of hair pulled out in stress.

Seriously though, there's clever code and then there's just nitpicking. Micro-optimizations with JSON.parse() look ugly and nullify some editor conveniences, but they're IMO very far from being a fireable offense.

[Drdrdrq]

They are not a fireable offense in my book either, but they sure as hell wouldn't pass my code review. I've had to deal with too much crap like this in the past. Self-proclaimed senior devs that micro-optimize everything and leave a mess, then leave. Love them.

One should always optimize for easy maintenance. Performance is always a secondary goal, because it doesn't matter how fast (you think) your code is if you can't understand it.

[quickthrower2]

Well I agree, you don't fire the person because they put JSON.parse(...) even if they put it in 1000 times. That would be silly.

The question is WHY did they do that? I'd probably get them to learn about performance tuning and do some profiling, make something faster. When they find out that it's slow because of something they didn't predict, hopefully they'll decide for themselves that they can't predict what will be slow, so no point complicating the code. If they don't get that, maybe explain it to them.

Basically the person who put JSON.parse all over the code was learning.

If they come back and arrogantly say "I'm right, and I'll carry on doing it you won't stop me", then that could be an attitude problem that might lead to question if they should be working there.

There are more nuances like if the person is claiming to be a senior developer/architect then the trigger for firing them might be more likely to be pulled. But still it is worth thinking about it first.