[iamasoftwaredev]

> This development came at extraordinary cost for the org and, in the case of the people who were laid off, cost to people's careers.

Except the people who were laid off, if they have been there a while, got much deep knowledge than if they just glued together a bunch of AWS stuff.

Gluing together AWS stuff can get you a good job, but it's not the same as solving these sort of problems.

I'd rather spend 3 years working on this and get laid off than the way I spent my last 3. Guarantee I'd be in a much better spot in the job market too.

Instead I'm trying to figure out how the fuck I get my career back on track because I'm headed towards the sort of job I will hate every single day.

[hyperbovine]

> but it's not the same as solving these sort of problems.

But that's just it: the problems were not solved. Personally I would rather devote years of my career building something that actually works by standing on the shoulders of giants, than going full NIH and wasting those years on a clunky POS that will be mothballed before the decade is out.

But hey, I chose science.

[braythwayt]

And there, ladies and gentlemen, is the source of the problem: People who think, Solving a general-purpose problem that has already been solved by somebody else will do more for me personally, than using somebody else's solution to solve the problems my employer actually has.

I remember doing that too, once upon a time. I invented a templating system based on Lisp for building web apps, back in the days when there were servlets, but no Java Server Pages (or Handlebars, or jsx, or anything we have today).

The templating system was wonderful, and it did improve developer productivity for our group, but there is NO WAY WHATSOEVER that it paid back the time I put into it.

The business would have been much better off if we'd simply used what was available and spent the majority of our time solving business problems, not developer productivity problems.

Furthermore, my templating system didn't wind up being that special. You know why? Because I wasn't really solving a business problem with it, so I had no constraints upon my design. Without constraints, such things meander from shiny bauble to shiny bauble according to the engineer's whims and fancies.

When you're solving an actual problem, you have constraints in time, resources, and solution. This forces you to create actual value. That makes what you build actually useful. But when you're building a thing because you want to play with the thing, you have no constraints, and rather than freeing you to create something amazing, this simply sucks you into making something that is worthless for anything except résumé-building.

"Ah, but my résumé," says the narcissist who feels no obligation to create value for their employer. I have bad news, and I am speaking from experience. If you build a bunch of things with way-cool tech that created no value, you become an ignorant person's idea of a smart developer.

Sure, you can get hired by people who don't really understand how to manage engineering, and they will throw money at you, but their ignorance combined with your self-serving ways will result in another disaster. Lather, rinse, repeat.

Good engineering cultures will ask you about your projects, and they will ferret out the fact that your projects did not add value, and did not "move the needle." I am not hypothesizing this, I have gone to interviews and had the interviewers grill me on my vanity efforts.

You cannot pull the wool over the eyes of anyone who has been through a cycle like this and is determined to never have it happen again. You can put lipstick on a pig, but there's no way to hide the fact that all projects like this wind up becoming ad-hoc, informally-specified, bug-ridden, slow implementations of half of the thing you should have used instead of building your own.

Now all is not doom and gloom. For everyone who has done this, either deliberately or by being dragged into one of these white elephant projects, there is a way to supercharge your career going forward.

Instead of boasting about your ability to write Lisp-based templating systems, or synchronization protocols based on Operational Transformations, or whatever it is you built, try confessing to it.

Point out the engineering experience, but then be up front that the project was a failure/bad idea. Sure, point out that you learned some great tech. But spend much more time talking about how much you learned about failure modes for projects. Talk about the scars.

Companied worth working for are eager to hire people who know better. Position yourself as someone who has learned these lessons the hard way.

[iamasoftwaredev]

> Companied worth working for are eager to hire people who know better. Position yourself as someone who has learned these lessons the hard way.

Learning those lessons the hard way still requires doing those projects, which means you learn how the tech works, which means I still feel 100% justified in my previous statements.

I want to work on a project like this that actually has lasting value to the company. Actually does something novel enough that it's worth doing.

How do I get there? Is the only way to win the lottery and get placed there as a new grad/junior engineer?

Cause that seems like what you're saying.

[braythwayt]

My actual advice--for whatever it's worth--is that at the outset of your career, it's better to chop wood and carry water on successful projects in a good engineering culture, than to collect buzzwords working on projects doomed to fail in a weak engineering culture.*

I know it's very hard to get jobs in established good companies, but there are also quality startups, founded by people who have these kinds of scars already and won't go down the path of building things nobody needs.

Here's a specific tip:

When interviewing, there's a point where you get to ask them questions. Great! Ask about projects like these. Is the company working on any of its own tech that could otherwise be rented from Amazon or is available as open-source? Why? What is the expected benefit? If not, how do they manage development to stay focused on projects that deliver value?

By asking these questions you will identify engineering groups that are strong or weak, and you will also send them a strong signal that you care about success. Good companies will pick up on that signal and be more inclined to hire you.

JM2C. My advice plus $3.00 will get you a latte at Starbucks.

----

* This is not a dichotomy, of course.

[kazinator]

Someone had to build the "thing you should have used instead of rolling your own".

Most of the things we should use instead of building our own are either currently someone's shiny, golden side project with no business case, or else started that way.