TEC Talks Podcast: Unhappy Programmers

Today in the ACSL podcast studio,

we have a very special episode for you.

We will be discussing the Stack Overflow 2024

developer survey with a specific focus

on the frequently seen headline stating that,

apparently, 80% of developers are not happy.

In the studio, we have a few special guests right now.

There are four of us in here, including myself.

I'm going to go ahead and kick it over to each of them

to introduce themselves real quick.

First in the studio, we have Andrew over here.

Andrew, why don't you go ahead

and introduce yourself real quick?

Hello, I am Andrew.

I am one of the board members on tech

and I have worked a number of years as a software dev,

so I'm a mid-level backend software engineer.

Thank you, Andrew, appreciate it.

And then over here, right in front of me, we have Ryan.

Why don't you go ahead and introduce yourself?

Hello, everyone.

My name is Ryan Jones.

I work primarily as a embedded systems developer.

You can call me mid-level,

but had a lot of experience working

in a couple of different industries.

Awesome, thank you, Ryan.

And then to my left here, we have Connor.

Why don't you go ahead and introduce yourself, Connor?

And by the way, Connor has actually been

on the podcast before.

We have heard from him for dedicated listeners,

so he is making a comeback.

Yeah, thanks for having me back.

Yeah, so I'm Connor.

I'm a UX UI developer.

I'm a little bit more on the greener side of things,

a little earlier career, but I'm still excited to be here.

Excellent, thank you, Connor.

And then last but not least, we have myself here,

which I have also participated on this podcast

a few times before.

My name is Chuck.

I am the CTO of the Technology Education

Collaborative Nonprofit.

This is what brings us all here today.

I am also a senior level software engineer.

I do full stack.

I also do a lot of Linux type stuff,

and I pretty much just love coding.

So why don't we jump into it?

What we wanna talk about today is we wanna figure out

why people might possibly be unhappy, right?

So I have up here on my screen the satisfaction levels

for the 2024 Stack Overflow survey, right?

And if I add up the numbers here,

it says for this particular item, 6.3,

it says satisfied at current job.

Only one in five professional developers

are happy with their current job.

It's about 20.2%.

We asked whether they were satisfied

with their current role, we being Stack Overflow,

and 48% indicated they were complacent

while 19% were satisfied.

So I'm kind of seeing here, we have three little sliders.

It says not happy at work is about 32%.

Complacent at work is about 47.7%.

Happy at work is only 20%.

So if you do the math, you do indeed see that roughly 80%

are not answering happy at work.

I think, you know, just from like a high level

personal preference perspective,

I think being either happy or complacent at work

are good places to be.

Would you guys kind of agree with that?

I see some heads kind of agreeing with that.

Andrew, what do you think?

Complacent is easy to stay at

and it is an acceptable goal to have.

It's hard because now you're not advancing yourself,

but still better than not happy.

I think I would agree with that.

What about you, Ryan?

I'd be interested to see the experience level

of the people who answered these, right?

Because there's that sort of honeymoon phase

when you start a job where you are very happy

and then as over time you could pivot

to being more complacent in the job setting.

But I definitely agree that complacent

isn't necessarily a bad thing

and it can be satisfactory at work.

Yeah, good thoughts.

What about you, Connor?

Yeah, I totally agree with you.

I will say one of the things that kind of popped out at me

is that satisfaction and also happiness,

sometimes they don't always correlate like one-to-one.

So I do think some of the wording

could be tweaked a little bit in the survey.

That's a really good point, yeah.

Cause you might be satisfied at your job,

like maybe provides the intangibles

or rather even just tangibles.

Like it might have a good set of benefits

or a good healthcare plan

or something else that really works for you

and that leaves you satisfied,

but you may not entirely be happy, right?

That's kind of what you're getting at?

Yeah, exactly.

And to add to that point, yes, it might be a job.

You spend eight hours a day doing it or more

and sure you're complacent,

but that's what outside of work is for.

If work helps fund being extremely happy outside of work,

complacent sounds great.

Yeah, it seems like an admirable goal to shoot for, right?

It is also important to note

that this is a technology focused organization.

The TechEdCollab is focused on educating people

about the thoughtful use of technology.

We are all very passionate about it.

That's why we're here.

There are many people who strive to get into tech

and our goal is to help them get into tech.

So we want to really highlight for everyone listening

that we want to make a clear picture

of what to expect in the industry

because that is part of the education, right?

I think everyone here would agree with me on that,

that while every job does have its downsides

and people do end up unhappy in some circumstances,

our goal is to paint a realistic picture of things

and not to lead people astray.

So each of us has brought forth a talking point

that we're gonna go through

with the idea of understanding

why people might be unhappy on the job.

So I'll go ahead and start with my point here.

One of the things that I've had

over the years that I've been doing this

is concerns about code quality and confidence, right?

Any company that is seeking to deliver a tech product

wants to be confident in their product,

that it will work the way that's expected, right?

They want to have a reliable set of software

that they're shipping to their customers,

otherwise their customers won't come back.

That's kind of the whole point, right?

If you ship something that may or may not break

and no one really knows for sure how much it's gonna break,

that's kind of a shaky foundation to live on.

So one of the things that I think

kind of rears its ugly head from time to time,

more often than I would prefer,

is the idea that businesses are always trying to

sort of push and push and push

to the point where sometimes engineers

may not have enough time to consider

how reliable or unreliable their code is.

And if I'm gonna get a little more specific with that,

what I'm really trying to get at

is stuff like unit tests and integration tests and QA, right?

When I write software,

I want it to work the way that I intend it to work.

And sometimes I write code that just kind of sucks, right?

First time I run it, it doesn't work.

Eventually though, it does work.

And a lot of the times when you're doing development,

you do write unit tests to kind of assert

that your code works the way it's supposed to.

And running these unit tests is ideally done in a way

that's repeatable, quick, doesn't require any dependencies,

that kind of thing.

And unfortunately, I think that a lot of companies

just simply don't have the time to invest

in a solid, robust unit testing infrastructure setup.

And that's hard, I get it, I really do.

But I just want to really bring attention to the idea

that with a little bit of discipline

and a little bit of agreement in advance

on how much unit testing should be done,

better code quality can be achieved.

Simple bugs can be ironed out.

Usually the process that I take is I recommend

don't ever go above 80% code coverage in unit tests.

If you wanna be happy and not have to deal with crazy mocks

and things like that, monkey patching, whatever else,

I understand that even 80% may not be achievable

in all cases.

But I think that there are great benefits to be found

from just simply pushing for some level of unit testing.

I'll kind of kick it to you guys real quick

to share any thoughts on that regard.

Andrew, do you have any thoughts on that?

I do want to point out one thing.

Stack Overflow factors that can most contribute

to job satisfaction agree with you.

Improving quality of code is the highest rated thing

for something that would contribute more

to being satisfied and or happy at work

to pull from the 32% that are not happy

and move them higher up that chain.

The tight rope of balancing between there's deadlines,

you gotta pull in money with the software,

but the software has to do the thing.

And then there are people within the org

that will promise the moon in the world.

And now somebody has to make that with,

and these promises were done without an understanding

of what that actually means.

Excellent thoughts.

Ryan, what about you?

Unit testing and code quality is super important.

And when it comes with different types of developers,

you don't want to feel overwhelmed, right?

So if you're only working on unit testing, for example,

and maybe your goals are aligned with something else,

that could influence your satisfaction of job quality.

Connor, what about you?

This does kind of remind me of something GitHub did

a while back to where they were seeing similar kind

of issues within their employment body.

So they went through and they put a pause

on all the new features they wanted to add to GitHub.

And they said, okay, what we're going to do is

for the next few months, we're just going to focus

on fixing all the other problems we have.

And that actually ended up working surprisingly well

just for employee satisfaction.

So, I mean, it does kind of prove what you're saying that,

hey, if maybe we spend a little bit more time

on the backend fixing all these bugs and stuff like that,

overall, it's just going to lead to a better environment.

It kind of sounds like the idea is that people

are getting a little anxious about their code, right?

They feel like maybe they just aren't in control anymore

and everything is kind of wishy-washy.

And giving them that time to improve the strength

of that code base makes people a little more happy.

Would you agree with that, Connor?

Yeah, I would totally agree with that.

I think a lot of it does come down to ownership

and feeling like you are putting a little bit

of yourself in your code base, so yeah.

Let's kick it over to the next talking point here.

Go ahead, Andrew, why don't you share with us

your perspective on why you think people might be unhappy

in the industry?

You never really feel like an expert.

Technology is so far reaching and in terms of breadth,

as well as so deep nowadays that the specializations,

such as for me, backend engineer,

now there's specializations of the specializations

because everything is so different and complex.

So any small changes, going back to the code quality,

you have to spend a lot more time on it.

And if you're not an expert,

that's a lot more time and likely less quality.

So that's one of the things for me.

And my experience was they wanted to swap devs every quarter.

So whatever team you were on,

you got a different team the next quarter.

I was very much not a fan of that practice.

Ryan, what do you think?

I think he brings up good points

about how technology is changing so fast

and how there's this constant evolution

to try to learn new things,

as well as keep up with your doing currently, right?

You don't wanna be doing a skill

that might become outdated in two years

and then suddenly you don't have a job, right?

So I feel like in terms of job satisfaction

with developers, having that feeling of growth

and being able to constantly learn new things

and apply it in your daily job

can influence your satisfaction and job quality.

I do think it comes back to having a good quality team.

I do think every quarter, getting a new team,

that's gotta be really stressful for a job like that.

Because when you're learning

all these different new technologies,

sometimes you fall back on your team to be like,

does anybody else know how to use this tool or whatnot?

So I could definitely see that being a serious issue.

Depending upon the quality of the code base

you're working with,

if it's one that's not great quality,

now you need more depth of knowledge.

If it is one with good quality,

that depth actually shallows out, which is nice.

Yeah, I think the idea that you're moving to a new team

every quarter is kind of insane to me.

I mean, it can take a month or two

just to figure out a code base.

I'm curious, do you remember how big the code base was

for each of these teams that you kind of went on?

Because if it's a big code base,

there's no way that's sustainable, right?

It was very big, larger than big,

because this was a code base that included authentication.

It included document processing.

It included the database.

It was a very monolith of a code base.

And there was an entire rewrite slash refactor

they were attempting to do

of this incredibly tightly knit code base to pull out.

So not having a depth of knowledge,

yeah, I was not happy with my code quality from that.

So why don't we kick it over to our next talking point.

I believe, Ryan, you're up next.

The topic I wanted to talk about

was having the tools and resources

to set yourself up for success,

whether that's through mentorship, training resources.

One thing I like to do is set a goal for myself.

In six months from now,

am I gonna be better or worse than I was off, right?

And I think that's like a good metric

I set myself up for in my career.

So one point I see on here

is contributing to open source being a satisfactor.

And in my day job, I actually do have the opportunity

to contribute to open source

because there's like a tool that we use that is highly used

and there's not a lot of people who know how to do it.

And I think that being able to contribute to open source

is, it feels very good

because not only are you doing stuff that benefits you,

but you're helping the community.

And I think that if you have the opportunity

to do something like that,

it can influence your satisfaction in a job.

Yeah, having the tools as well as goals and environment

to promote yourself, that's a great thing.

Having the goals set by other people, ooh, that hurts

because those goals are now business aligned,

not personally aligned.

So setting your own goal, like you've mentioned, great.

Yeah, I totally agree with you.

It's also nice because there are a lot of tools

and articles based on kind of what you're talking about.

So it is a lot easier for people to learn

like better management skills

and also to learn some of these different tools

because not only do you have

maybe the official documentation,

you might also have like some open source,

like projects that are trying to promote usage

of the different tools that your company might be using.

Yeah, I definitely agree with what Ryan is saying.

So I think it's really important for people

to be able to contribute to open source projects

either as part of their job or outside of their job

because that builds the community up, like you said.

And also it lets you kind of improve your exposure

to different sets of software and different tooling

and different technologies, different frameworks,

different whatever.

I also think that if you're working at a place

that genuinely respects you as a person

and wants you to grow, they will hear you out on your goals.

They will hear you out on how you want to grow.

And that's really important.

When I worked at a more big tech type firm,

all of the management that I appreciated working with there

thought and gave careful attention

to my own personal goals and career growth.

So if you're at a place that says,

we're only thinking about ourselves

in terms of the business,

definitely give that some second thought.

You know what I mean?

Connor, what is your talking point?

So something that I think should be brought up

is that with Stack Overflow,

I have noticed a lot of people who use it

tend to be a little bit more green

and trying to get like a foot in the door in the industry.

And also if you look at the Stack Overflow survey,

there's a question about your educational background

and there are a fair number of people

who have like college degrees.

And so I think a lot of the dissatisfaction

comes from thinking that you are prepared

when you really might not be 100%.

So I think that creates kind of a false sense of security.

Like, hey, I'm gonna go out there,

I'm gonna get a job in industry

and I'm gonna be able to do what I need to do.

But unfortunately, I think with the way the world

has kind of been these past couple of years,

the industry has just shifted a lot

with like the introduction of AI

and then also COVID didn't help very much.

So I think that definitely has kind of changed

how the industry works a little bit.

Yeah, I think I have a quick reaction to that.

I think that when you graduate from college,

you have a degree, like you said,

but then you're really just honestly expected to know

how to work with Angular or React

or whatever trendy framework is taking the industry

by the horns, so to say.

And you don't really learn those frameworks

when you're in college,

unless you go to something more specific

like a technical institute

or some kind of coding bootcamp.

And neither of those are long enough really

to build that experience,

at least coding bootcamps usually aren't.

Those are only a couple of months.

So I hear that definitely being the case.

And in fact, it's one of the reasons why

I think a lot of people come into a job

that are just completely unprepared.

Like they don't even know how to use something like Git

or maybe like certain IDE tools

that are just very common in the industry,

but you don't learn about them at all in college.

So there's definitely a bit of a mismatch, right?

Like you did all this work to get a degree,

you had all these crazy student loans

that you're now having to pay off

and then you get a real job

and it's actually quite different from what you thought.

And for myself, there's also a mismatched expectations

of, yay, you got a college degree.

I'm gonna be hired in a month, right?

And then five months later or six months later,

because depending upon job market, is it good?

Are they actually going to hire new people

or is it, no, we're only hiring

for like senior level positions

because we don't have the bandwidth

to take the time and train our new hires.

Yeah, and just to think about that too, Andrew, right?

Every year there's gonna be more and more CS grads

that are graduating with CS degrees, right?

So to some degree it's inflation.

There's more people with just college degrees

and it's almost becoming the bare minimum, the expectation.

You have to come up with different ways

to set yourself up and learn new skills

as well as be unique.

I think doing organizations like tech or extracurricular,

I got most of my skills in college, not through classes,

but being involved with community

and getting hands-on with projects.

And then also what I mentioned before, open source, right?

Anyone can contribute.

That's almost like a free internship, right?

You get skills contributing to open source

and suddenly you're doing the same thing at a real job.

So I think those would be really good resources

to consider when trying to pivot in the job market.

I'll echo that sentiment.

I actually had a ton of people

over the last n number of years really set me straight.

I would do stupid things when making poll requests

or I would make code changes that were unsensible,

but I didn't know at the time

and they didn't mince their words.

They told me, don't do this, don't do that.

And I learned, I learned fast.

And I think that that kind of stuff,

you can really only get in the open source community

because there's really nothing to lose

except for maybe a bit of pride, I guess,

by trying to make a code change somewhere, right?

Someone's gonna tell you, no, we're not gonna merge this

and maybe nothing happens.

Maybe something does happen,

but that's a great perspective to have, right?

All right, well, that is it for this episode.

This has been a very special episode.

We are thinking about doing more variants of these.

I personally really enjoy talking about this

and I wish we could go longer.

In fact, I think maybe in the future,

we will expand on different parts of the survey,

talk about different areas

of ways people are engaging in the industry.

If you are listening to this now

and you want to get involved somehow with tech,

send us a topic to discuss.

We are happy to hear you out.

I wanted to give a huge thanks to Andrew, Ryan, and Connor

for joining me in the studio today.

So thank you guys.

Thanks for having me.

Thank you, everyone.

Yes, thank you.

I'll see you next time.