redleggedfrog

I'll contribute by telling an anecdotal story.

Our company was hired to take on a project that was failing. It was an order export and update system between a website and an ERP system, neither to be named for the obvious reasons, and of fairly significant mismatch between the data in the two systems.

It started with some visual tools for the data flow, got a shit-ton of node and random libraries piled on, running on a hosted service with a deployment system for faster updates cause it broke constantly. It lost data 5% of the time or just failed to export the orders. It was shuffled around to different groups which changed up how it worked.

If I had to work on it I'd have quit. Instead I rewrote in 3 days in .NET Core C# as a console app running on a schedule using Json.net, XElement and hand written transforms and it was fun. Copied it up, got it running, buffed off a handful of rough edges for about 2 more days of work and it's been running fine since. No updates needed no data or orders lost.

My point? Reject all that shit that is just bad languages and bad systems and poor choices. Do it with what makes you and the client happy. Clients don't care what it's written in the just want it to work. So choose what you like and gets the job done and lets you move onto the next fun thing. If you don't enjoy your work you're trading your life for money.

Information wants to be wrong.

And somehow they did it with the absolute worst client you can imagine. The UI is excellent at getting you not to use it. I would pay for a subscription if they actually put some effort into a native application for Windows instead of Elecron or whatever crap web tech they built it on.

Until then my CD rips will stay.

edit: tips to rips

Layoffs signal weakness, from every angle. They hired indiscriminately and now are doing catch and release. Or they lacked foresight of their market. Or they are financially mismanaged. Or they are directed by a unqualified board. Or they are unable to cope with their market shrinking. Or they are a behemoth that grinds up workers as part of their operation (a lot of what we're seeing now). Or they're jumping off the cliff with the other lemmings. Or they need money for upper management pay.

When you're looking for a job, keep the companies previous layoffs in mind. Are they stable, or do they acquire and jettison?

So one 1 out of 20 are getting let go. Looking around near 50 employee company I work for I easily see 2.5 employees I would let go just because they're near useless. Hell, I'd say it's at least 5.

I'd say unless you've got a good manager, really good hiring, and are keeping close tabs on the technical people (just to make clear, I'm one of them those technical people) I figure you've at least got 1 our of 20 you should just be sacking on principle.

> What real human problems have you all resolved that lifted the lowest in society without the kowtow to those of high net worth (another appeal to imagined authority)?

I'll admit that my profession is no more noble than say, a carpenter, and is primarily to fund my desired lifestyle. But I don't work at a startup and I don't make startup money and I'm certainly not a coder bro (after my time). I can't say I've "resolved" any real human problems either, but I do occasionally try to do something to help. Over the years I've coached youth sports, tutored reading and math for underprivileged or ESL kids, collected food for the local food bank, played harmonica in a jug band at the local old-folks home, taught after-school bike repair, do roadside cleanup, and was going to do books for inmates but it got cancelled due to COVID. And lest you think I'm trying to get into heaven this all comes from my cold dead atheist heart in the chest doing all that bumping. ;^)

That is a an interesting insight on BSing and I appreciate you being so upfront about it. Your response is why I like HN so much - you gave me an angle I didn't have to ruminate on.

It's going to be an unpopular opinion, but software development is an awesome field for BSers. Because most of the people you answer to don't know the details of what you do, you can totally make stuff up, explain failures with magic or noise, and pump yourself up by claiming something you did was more difficult than it was, combined with talking like you know everything - the more confident the better. You often get to make your own estimates as well, so moving the button one pixel to the left can be a week.

In the last 15 years I've seen this quite a bit with new hires. Self proclaimed experts who can talk extremely convincingly, who have passable domain knowledge, and very little practical ability. The code they write is usually junk, or worse, actively a problem. Because I do not have a forceful personality and our upper management is mostly clueless, these people prosper in the beginning, but eventually they shit where they eat so much that end up creating an unmaintainable morass and choose to move on. Every last of one them.

I guess they fall into the "just enough knowledge to be dangerous" category.

There a lot of thoughtful responses here except they miss the point that having an opinion is useless in almost every case except to make decisions about your own life. You will almost never change anyone's thinking expressing your opinion, and mostly it leads to a pointless debate when expressed publically (online). Just say what your preferences are and maybe why and leave it at that. Essentially no one cares what random people's opinions are.

I'm frequently on that receiving end of low-code implementations that have failed, and I'm not quite as fond of it as you. ;^)

The problem is reasoning. Often the low code limitations funnels the implementation into a contorted state, so by the time they've decide to give up what I get is frequently exceptionally difficult to comprehend. Usually I peek at it, try to get an idea, and then do what I would have done if assigned to task from the get-go - read (or make) a spec, and go from there. I'm doing some quick napkin calculations from the time tracking system, and the ratio is approximately 13/2 on the last 7 of these no-code to code tasks. What they attempt in no-code in 13 hours and fail I finish in, yes, 2. Given, these are not developers, and sometimes these actually come from the CEO (who does not track their time so they're not in that ratio), but mostly they're just managers and remote hires. And I've been developing software for 28 years now, so I have some capability. Also, these are mainly data related projects, so maybe other types of work would have more success.

No code will get better, I'm sure, but the problems we're solving actually are getting harder (it seems to me) and reasoning about them is the difficult part. I'm not sure how to no-code that.

Write the essay in person, no phone allowed, then you'll see how those little cheating jerks really do.

"I posit it becomes increasingly likely over large periods of time over many engineers that severe bug or security issue will be introduced via an AI provided suggestion."

I'll go one further with the "Co-pilot is stupid."

It's supposed to be artificial intelligence. Why in the eff is it suggesting code with a bug or security issue? Isn't the whole point that it can use that fancy AI to analyze the code and check for those kind of things on top of suggesting code?

Half-baked.

Alright people the talent pool just got more fish. Go get 'em!

I would add "Don't write code unless you have to."

I love the irony that the site displays a blank white screen for me. Well done!

Also could be thought of that the emissions aren't somewhere around double, thanks to CA's efforts.

Yes, but can we buy it yet?

...that runs on .NET. :^P

My company is not hiring developers at the moment, but there sure are some people who should be let go.

Honestly, that list above has lots of things Seniors probably could brush up on.

1st world problems, man. Go volunteer at a soup kitchen to get some perspective. Also scientifically proven to lift your spirits.

Arr, matey! There's a solution to this problem.

"WFH will reduce middle management..." I find that an interesting idea, because at my company the introduction of work from home has increased middle management to herd remote cats. Because you can't just talk anymore, you have to document every last effing thing, and then have interminably long meetings to go over it. I'm skeptical. WFH seems to be a middle manager's dream.

Based on my experience with such firms this is the prevalent modus operandi. Hence I don't trust them. In our company we cannot commit code without review, and this turns up these "replacement" developers pretty quick. But it's pretty disheartening. You don't even make it 5 lines and there is .ToString() on a string, and it just gets worse from there.

I used to take some effort in trying to be nice about it figuring the person probably who wrote the code doesn't know they're a replacement and is just doing the best they can, but I eventually stopped caring. Now I just butcher them, point my boss at it, and see how long it takes before they get fired.

Ug, working on weekend, drag. ;^)

comfypotato, sorry for the delay in replying, I only read Hacker News morning and evening.

Hmm, a single "most helpful tip" - that's tricky.

Okay, how about, "read a lot of code and write a lot of code".

Thing is, I really like programming, and would do it even if I wasn't paid. Early on, way back in the DOS days, I wrote most of the programs I used - contact manager, calendar, compy automation and so on, in C, then C++. Then when Windows came along I wrote the same things in Borland Delphi.

When I want to learn something, I spent a fair amount of time studying up front, but I learn way faster just starting to write something. Walking through with a debugger tells you a lot more than docs. Professionally it has been much the same. I work on a lot of legacy systems. I learn the code, usually by debugging, and then when asked to do something, I usually refactor to be more modern and reusable, and then do that reuse when possible. I'm not really a neophile so if I have a bunch of services I've used for 5 years that work great I'll just keep using them. Everything gets done with an eye for re-usability. I love solid code I can depend on.

Also, I keep really, really, stringent coding standards for myself, and the Dev team is mostly the same. We've agreed to these as a group, so we code review everything for SOLID, KISS, and conformity to our code review guidelines. It makes reading code a lot easier.

I hope that helps.

Reading the bullets for a minute I thought I was Bob, but I've never done Android for real, so no, but the rest mostly fits. I'm maybe not quite that productive, either, but close. I have the advantage of being old and curious, and working with the same codebase for the last 10 years.

What helps me is a really good manager - of which I have had two out of ??? in 25 years. When I'm out of tasks they allowed me to refactor and fix longstanding difficult bugs. It has the added advantage of getting me deeper into the code and allowing me to build better foundations for future work which makes me more productive for a nice feedback loop.

They also have allowed me to train up other developers and write up official coding standards with down time and that has been great, too. It's nice when all your code looks mostly the same.

Also being able to repeatedly decline a promotion to management but still get paid well has been good for company loyalty.

There is a downside in that most days feel like, well, kind of like a Games Workshop orc going "Waaaaaaaah!" where I'm just hurtling through the work and my brain is just spinning max RPM and then I go home and it's hard to stop the momentum. I have to excercise to clear my head or I won't sleep.

I wish. West Coast of USA can fire you for a bad haircut.

Yeah, that's a little bit of the story that I left out - he also chose React without the normal team consensus on tech, so there was that, too.

Nope, dude at my job totally got "laid off" for choosing to write a feature in an ecommerce system in React. He had used it before at a previous job and was familiar with it. Problem was:

- No one else in the team was familiar with React.

- React did not play nice with the rest of the app and developer work flow.

- It was huge and slow

- He didn't know React as well as he thought he did and we had endless bugs.

- He spent ages working on it.

We rewrote in vanilla JS in 4 days - one dev.

And, yeah, effing JS.