[taylodl]

I feel like this is completely backwards. To me this feels like 'I love using this kind of hammer so let me find all the jobs where I can use this hammer I love to use.' I'm actually not interested (at least not primarily interested) in that. I'm more interested in what are you building? What problems are you solving?

I'd rather search by that and then see what their tech stack looks like and filter down to the ones matching my interests and the tools I like using. Heck, there may be a company that I'm really interested in what they're doing but I may not have a lot of experience with their particular technology set. I could reach out to them and express my interest in what they're doing and see if it might make sense for me to join them. Focusing on technology feels like putting the cart before the horse.

[beecafe]

I don't care one mote about solving problems. I program because it's fun and I'm good at it, so I have no space for bullshit MBA puff like "solving problems" (it's not) "making people's lives better with technology" (it never has or will). So for me working in a place where I get to use the tools I enjoy is more important than whatever flavor of the week justification is given for the rent we are seeking from and new problems we create for consumers.

[NAHWheatCracker]

This is an interesting take to me, because it seems to be how many of my coworkers work. It's not how I think about things.

I enjoy technology, but it's hard for me to just focus on tech without a purpose for using it. All of the projects I'm proud of aren't because of the tools I used. Instead, I'm proud that I delivered something useful.

Yet, I still completely agree with your statements about "MBA puff". I've been on projects where they extol how valuable a project is going to be and it doesn't stand up to a minute of scrutiny. Other projects would be valuable, but never get into the hands of real users.

On the projects I'm proud of, I was directly working with someone who actually would benefit from the project. There wasn't a question of whether it was worth it. The users weren't puffing up the project to be more than it was. They have a job to do and I'm helping them do it better. Interestingly, this also meant that they didn't care how I approached the problem.

The real sweet spot for projects is where working on interesting tech goes hand-in-hand with delivering something useful.

[mwcampbell]

It's unfortunate that this cynicism is so widespread, because technology actually does solve problems and make people's lives better. I suppose I'm lucky to be working in a domain, accessibility for blind people, where this is obvious. But I'm sure there are many other such areas.

[znpy]

It's not cynicism, sadly.

There are a ton of jobs that are tool-heavy, and the "solving problems" only applies to a small percentage of the team.

Some problems should not exist at all and only exists because of the tooling chosen.

Example: A friend of mine works at a company that is running their business on some clown-ish cloud infrastructure, and their SREs have to basically re-invent the wheel to work around the limitations of the cloud vendor the management has chosen (for example: no virtual machine autoscaling, in a cloud environment). Somebody at that company is certainly doing "creative work" and "solving problems" with code, but not those SREs.

[AnIdiotOnTheNet]

It can, but parent's cynicism is very understandable if one looks around at the hot new exciting technology of today and compares it to the hot new exciting technology of decades past. Pretty much the entire high-paying tech space right now is either solving non-problems or actively creating and promoting problems.

[nominalbkfst]

Its not so much that I need someone to try to sell me that I’m changing the world instead of making a paycheck. But I definitely would rather clean toilets for a cause I love than work with cool tech on a project I don’t believe in or that doesn’t ever go anywhere.

When I was younger my family was really big into riding ATVs. At first it was cool, but then I started to realize we were just going to drive in the same circles at the same parks forever and it lost all meaning to me. ATVs are cool, I still think they are, but without a reason to ride one I can’t imagine spending a weekend in a tent driving around in circles. At the same time I know plenty of people who live for that, so I recognize that we’re all looking for our own things.

[arcturus17]

If software does not solve problems, what are you getting paid for, exactly? For the weight of the line of code?

[willcipriano]

What is a plumber paid for? You tell him you'd like a sink installed somewhere and he installs it. He isn't paid more if the sink is used to wash the hands of surgeons operating on orphans or never used it all. He is paid on the basis of, you want a sink and he knows how to install them.

[mwcampbell]

It seems to me that doing things on demand with no regard for purpose should be the domain of machines, not humans. Of course, robotics isn't yet advanced enough to allow us to meet that ideal in the physical world. But in the software world, the demand for programmers that merely crank out glue code, without understanding or caring about what it's for, should shrink, if it's not already.

[willcipriano]

I know why they are doing what they are doing, I'm just not paid for it. If I was paid by value produced rather than my skills I'd demand far greater control of the business, complete transparency and would refuse tasks that don't generate sufficient value. That just isn't the relationship most companies want, they would like to dictate what I work on and pay a flat rate for it. You can't have it both ways.

[arcturus17]

You want the sink because, presumably, not having a sink - or having a broken one, or an ugly one - is a problem for you.

Are we really discussing this?

[willcipriano]

Sure, but if everyone was able to install a sink the price of getting a sink installed would fall considerably. That indicates to me that you are paid based on the rarity and difficulty in gaining the skill, not the value of the problem itself.

[beecafe]

You don't get paid for solving the problem, you get paid for transforming the problem using software such that people become dependant on software to "solve" it. Now you can charge them for it. You can also insert software into places where no problems have been yet identified, make them dependant on it and then charge them for it.

[Existenceblinks]

This guy knows how business works. If everybody think hard enough, software is not needed in lots of situation. The market is all about forced solution, probably plus some network effect, social value yada yada that keep it alive.

[arcturus17]

> If everybody think hard enough, software is not needed in lots of situation

Yea, if you think hard enough, you can have communications sent by horse, instead of by electronic mail.

[Existenceblinks]

No, your example is daily infrastructure people already have. Maybe I say it too broad, there is layer of tool. You only need a few of them.

[arcturus17]

> You don't get paid for solving the problem, you get paid for transforming the problem using software such that people become dependant on software to "solve" it

Yes, the entire software industry is akin to crack dealers.

[anyfactor]

As a "Python Developer" this is for me. There are some demand for specific language based developer instead of purpose based developer. Case in point - Scala. There are Data Engineers and there are Scala Developers. There are some overlap but if you are an employer looking for Scala help, you need a Scala Developer and not someone who tolerates Scala in their stack.

For me, Python always provides the shortest path to solving problems programmatically. It is the best thing you can use to prove a concept before you build something. Python sits appropriately in the middle of pseudo code and something performant. I get to solve unique problems rapidly. That fits my philosophy. If you are comfortable in using something why not get paid to do that. I am open to learning new things particularly Typescript but I am just comfortable in a Python environment more than a JavaScript or any other environment.

The catch with all that is that I am more fitted for contract roles as opposed to full time jobs. For the employer hiring based on tech introduces too much rigidity. They want contractors and experts for that.

[__ryan__]

You are talking to a hammer asking why it isn’t a screwdriver.

[mettamage]

> Focusing on technology feels like putting the cart before the horse.

Every language has its own ecosystem, its own frameworks, its own culture its own set of "best practices". Good luck learning them all.

[FourHand451]

I don't think they're saying they can learn them all. Just the next one, if it can be applied to an interesting problem.

[taylodl]

Correct. The languages I learn outside of my day job are languages that teach me new ways of thinking about problems: Lisp and Haskell are two that come to mind. Do I expect to get a job where these languages are used? No. I learned them because it gave me insights for becoming better at my craft. It makes me better at solving problems using the languages actually being used where I work.

[francisofascii]

I think your are underestimating the time it takes to become proficient in a technology stack. You can't build anything until you learn it. When you are proficient, is nice to be able to come into a completely new business environment and be somewhat productive. It feels like validation that you are actually an expert in something. Now it is commendable and a great growth experience to come in as a newbie with no knowledge of the business and the technology, but still a hard pill to swallow for most.

[taylodl]

> It feels like validation that you are actually an expert in something.

You're an expert in knowing how to use a hammer. I think it's the wrong focus. Instead we should be focusing on whether you're a framer, a carpenter, a roofer, etc. It's your expertise in solving particular kinds of problems that makes you valuable, not in knowing how to use a particular tool.

As an aside, some people have noted this is not true for IT contractors - as they are oftentimes brought in explicitly for their expertise in a tool. I would argue that's a reason why a lot of people don't want to be a contractor forever.

[lkxijlewlf]

> I feel like this is completely backwards. To me this feels like 'I love using this kind of hammer so let me find all the jobs where I can use this hammer I love to use.' I'm actually not interested (at least not primarily interested) in that. I'm more interested in what are you building? What problems are you solving?

Same for me. I can learn whatever tech stack you're using (if need be). I want to know about your business, your product, your future.

[Existenceblinks]

But tech stack requirements sit right there in job descriptions. It's about matching.

[lkxijlewlf]

I generally disregard those requirements if it's a job/domain/business I find interesting. Current gig had requirements I didn't have. And now we have completely different ones from when I was hired.

[Existenceblinks]

It's not well-known nor standard, maybe companies should change how they write job description.

[taylodl]

Yes they do, but the question is should they? What role should they be playing?

[Existenceblinks]

They shouldn't, though they have few choices. They don't want to admit they chose the wrong tools for the problems, and can we disagree with them .. generally.

[Xenixo]

It's one tool of many

I like the idea.

I don't want to go back to a company which is not using kubernetes for example. I'm also interested in deepening my expertise in it.

[dagw]

To me this feels like 'I love using this kind of hammer so let me find all the jobs where I can use this hammer I love to use.'

Most craftsmen and artists I know are very particular about their tools and much prefer using their own tools that they've lovingly maintained and gotten to know all the quirks of rather than some random tool someone hands them.

[dagw]

As someone who is more of a domain expert who knows a fair bit of programming, rather than an expert programmer, I would certainly be reluctant of taking a job where I wasn't allowed to use the tools I prefer for solving problems within that domain.

[sokoloff]

It’s almost like people choose companies based on different factors.

Some are coin-operated. Some are language/stack-driven. Some want fast-growing; some want slow-and-steady. Others like small companies. Others like large stable companies.

[dotancohen]

You're a professional. I try to be, as well.

But I know many people who call themselves "PHP devs" or "React engineers" or "Wordpress gurus". This service is perfect for them.

[dagw]

How does one approach automatically make you more "professional" than the other?

[dotancohen]

There exist professional mechanics, and there exist oil-change technicians. The professional mechanic has literally hundreds of tools, of dozens of different types. The oil-change tech has maybe a dozen tools that he uses in an average week. The professional mechanic studies his craft and learns about suspension, brakes, engines, transmissions, electrical, fuel delivery, spark delivery, sensors, ecus, interior parts such as window motors, air conditioning, fuel pump replacement, diagnosis, etc. The oil-change tech can find the oil filter, screw it off, and screw on another one. Sometimes without even over-tightening it.

The "Wordpress Guru" is far more akin to the oil-change technician than to the professional mechanic. He likely does not understand HTTP, let alone TCP/IP, he might google CORS when he has a problem, likely copies code from Stack Overflow without understanding it, and has heard of Big O notation but has never had to apply it to his work. Honestly, I'm probably closer to that extreme than I would like to admit, but I do strive to understand ever line of code I'd be git-blamed for, and think that I understand two levels below the technologies that I do use on a day-to-day basis.

[dagw]

At the same time, I'm sure there are mechanics that love Ferrari, know everything about every Ferrari ever made and don't want a job where they don't get to work on Ferrari's. I wouldn't see that as sign of lack of professionalism.

[taylodl]

I think it's more like a professional mechanic wouldn't be happy being oil change technician. A professional mechanic may love Ferrari's, but also jump on the chance to work on Porsches if that means working on a GT Racing team.