AI and Programming Jobs

in ,

I recently argued with someone about whether the Great Recession or the current time is a worse period for people trying to enter the job market as software developers. She was positive that the Great Recession was worse, citing the overall unemployment rate of 9% compared to the current unemployment rate of 5.8%. However, that says nothing about tech specifically or new grads. At the height of the recession, workers with a degree (any degree) working in computer/math occupations had an unemployment rate of only around 5%. 

Given the gap between new grad unemployment and unemployment overall was about 1.7% in new grads', I'd extrapolate that it was likely around 3.3% for new grads. 

Let's come to today! Computer science has the 7th highest unemployment rate for new graduates at 6.1%, with computer engineering at 7.5% (sometimes this major is similar to computer science, sometimes it's more akin to electrical engineering, depending on the school). Clearly, new grads are faring worse!

Why

Here's a quick story time: I graduated in the spring of 2010, but I actually interviewed for jobs in the fall of 2009, which was a particularly challenging time to be job searching. I was about to earn an industrial engineering degree, had approximately 1.5 years of work experience, and had a very middling GPA. Even with that, I was able to go up to Home Depot in the career fair, ask what they were open to hiring ISyEs for, and, when they said "IT Developer," say "I don't know how to code very well," and have the response be "we'll teach you!" I got the job after a single conversational interview with a director, during which we just talked about running (I had just completed my first marathon). Getting a job after a single interview is not something that happens today. First, coding boot camps began to appear around February 2012. While I'm not a fan of many boot camps for several reasons, I'm pleased that people who thought they weren't capable have entered the market. However, the number of boot camps (and their graduates) grew at a pace that didn't match the growth of entry-level jobs. And they were now competing with CS students. Suddenly, getting an entry-level job becomes much harder for everyone. The status quo continued in this manner (with increasing numbers of entry-level candidates) until very recently. Even before the rise of AI, companies were finding it easier to hire senior developers due to constant layoffs. Because of this, many companies adopted the attitude of "Why hire someone I have to train when I could hire someone who knows what they are doing?" which I understand entirely from an individual perspective. However, it will lead to the long-term decline of the industry if people can't enter. So, even before the rise of AI, getting a job as a new graduate was becoming increasingly difficult.

The Rise of AI

Then, here comes AI. Reading any report about how great AI will be for developers and how easy it will make our jobs ignores how we started. Consider the post My AI Skeptic Friends Are Nuts. The author talks about how anyone talking about how AI code going straight to production is wild because, OF COURSE, you'd still be responsible for reviewing it! Valid. But how do you get to that point? An entry-level developer can't just look at code and tell whether it's production-ready. That takes time to build up that skill, and plenty of us miss errors when reviewing, even with years of experience.

You can also not learn that just by reading code, which, in this potential future, is all you'll be doing. An engineer I know said that he was excited about all this, and our jobs would change, but we'd just be more focused on quality. He then described the job of QA. QA is a job that companies in the tech industry have consistently devalued to a point where most companies don't have any QA and expect their devs to do that work (which really ends up amounting to writing automated tests and maybe doing some manual tests if it's a prominent feature). This magical future means I'm transitioning from a job I enjoy to something I'm not particularly skilled at (QA is a skill that most developers don't possess) and also switching to something that my company has already indicated they don't value. And also, this requires experience. I keep asking, "But how do people gain experience to be able to review AI code since all of us require boring, repetitive work to learn?" No one has answered this question, and it keeps getting deflected. Companies hire junior developers for what senior and experienced professionals generally consider "boring work." As companies increasingly push AI onto developers, the most mundane tasks are the easiest for automation. But without learning from that, how do they get to the enjoyable work?

Finding A Balance

There's a way to use AI to help us with our jobs without replacing anyone or replacing junior developers. However, it would require care, and after witnessing hundreds of mass layoffs at profitable companies, the care for people is not as strong as it once was. I'm not an AI boomer, but I use Copilot in my editor (still using DoomEmacs), and it's nice when I need scaffolding for something, and it just does it, allowing me to go back and correct it. However, it often comes up with methods that don't exist. And sometimes, they fool me because they resemble methods that do exist, and I think I must have missed something. And I've been working with Rails for 12 years. People should be more cautious than they currently are, but I don't see that happening. In the meantime, I'm starting to plan for what I'll do when my job becomes something I don't enjoy, which looks like it'll come sooner than I wish.

Ruby's "Bang" Methods

in

I’ve known for a while that there are a number of Ruby and Rails methods that use a ! (bang) at the end to modify in-place. Very convenient! What I didn’t know until very recently was how that might affect an object being passed in to another method. Here’s an example:

In 12 years of writing Ruby, I somehow never came across this until yesterday. I knew bang methods modified in-place, but I didn’t realize it modified the object even outside the scope of the function. Lesson? Don’t be me and be cautious when using the ! after a method name.

A Quick Git Rebase Tutorial

in ,

If there’s one thing you should know about me (technically), it’s that I love a good rebase. I loathe merge commits and a nice, linear commit history brings me joy. Since I am somehow leading my current team (who decided that was a good idea???), we are using rebase pretty heavily! I’ve found that people often get flustered with merge conflicts and wanted to do a quick tutorial covering merge conflicts and a basic rebase. Let me know what you think!

Yes, My History Does Influence How I Perceive Things

in ,

Recently I’ve been in a few conversations where people have questioned if I perceive things differently because of my history. I think that’s an odd thing. Humans tend to pattern match. There are things that I notice today that I wouldn’t notice as much earlier in my career. I don’t think that means that anything that happened earlier wasn’t that bad, but more that I was blissfully unaware. Here is a quick example from school:

When I was an undergrad, we had a year-long capstone project with a team of seven. It was myself, one other woman, and five men. Even though I had work experience in the domain we were doing our project in, none of the guys would listen to me when I said it was near impossible to accomplish. The other woman and I ended up hanging back and letting the guys crowd around a computer because we realized we weren’t being heard. We finished the project (which was a general failure because I was right), got an A due to the white male confidence of some of my team members, and graduated. When I did grad school, I ran into a similar problem. I was doing a capstone project with four men. We were building a web app. I was the only one with web development experience. They refused to listen to me. This time, I contacted the professor because I wanted the experience. I didn’t just want to skate by on little work because I was being ignored. Instead of helping, the professor just put me in a group alone, and I had to do the entire capstone project by myself. It was worth it, but it was frustrating that was the response.

I will do a quick, anonymized list of all the absurd things that have happened to me over my 13-year career. I think some of this is gendered, and some are just ????

  • Was told I sounded angry in emails. Started adding emojis, changed nothing else, and no longer got that feedback.

  • Got feedback on my review that I was abrasive.

  • Had a coworker who would sit and stare at me during meetings while pulling up his shirt and scratching his stomach. I cannot make this up. I am not that creative.

  • Had a coworker and a manager conspire to get me to quit by making my work environment terrible.

  • Have been the only woman on my team (sometimes all of engineering) four times.

  • Would ask a coworker questions (as a new teammate) and then have him say, “I’ll just do it.” I ended up having nothing to work on.

  • Had HR talk to me for saying no to an offer of a doughnut and mentioning to a coworker that I wasn’t excited about the offsite.

  • As the only developer, had the CEO listen to investors who had never looked at the code over me.

  • Had a coworker tell me that since I got the benefit of working from home, I didn’t get the benefit of coworkers answering my DMs.

  • Was told when interviewing there were several women in leadership in the engineering organization. After I started, I discovered there were none, and the only women were on my team, plus one person in QA.

  • Was told I should write down every step I have taken if I want any questions answered.

  • After telling me I did not need to take FMLA, I was told I wasn’t performing at level one month after my husband was hit by a car (he is fine now!).

  • Was accused of anti-Southern bias. I grew up in Northern Alabama and spent seven years in Atlanta.

  • Have been told I don’t change my mind multiple times after I have given an opinion, listened to the opposing arguments, and still not agreed… even if I’m happy to commit to the consensus.

  • Had a male coworker refuse to work with me because I disagreed with him, even though I suggested that we both present our ideas to a larger group and get more input.

  • Had a tweet mentioning “bad behavior from white men in tech,” and when two coworkers saw it, they decided it was about them. Instead of asking them to consider why they would think that, HR talked to me.

  • When I questioned something, a male coworker told me that it was “universal knowledge” that it was wrong.

  • Have been called “pessimistic” for suggesting that an idea was unlikely to work.

And honestly… that’s not exhaustive. That’s just what is on my mind right now. Also? This is only 13 years! I’m fully expecting to have at least 20 more years of work. And I’m getting wholly burnt out on DEI work… it feels thankless and like there is never any improvement. The teams I am working on continue to be more diverse, but the problems still exist. Some are even worse than they were on teams where I was the only woman. This feels like a hopeless post. I’m not hopeless! But I struggle to feel hopeful at the moment.

My Git Workflow

in

One thing I’ve learned as a developer is that everyone has a slightly different git workflow. Mine is pretty simple, rarely uses anything beyond the basics (other than rebase), so, if you are an early career developer, consider trying it on for size. Let’s get started!

I’ve just grabbed a ticket, so I’m ready to get started. First things first: I need to create a new branch off main.

git checkout -b my-awesome-branch

Now that I’m on my branch, I can start making changes. I will make one small change and create a new file. Now I’m ready to commit! But first, I must validate that the changes I’m committing are precisely what I want. You might think, “Jennifer, I just made these changes; why do I need to recheck it?” While it might seem silly, you will be surprised by the changes creeping into your commits if you aren’t careful. One really common one is dependency updates. So first: we will do a git status and a git diff.

command prompt showing the results of git status -s

You’ll notice that I didn’t just do git status but git status -s. The -s is for “short” and I prefer that because it gives me all the information I need in a nice compact manner. The M says that a file is modified and the ? means that it’s a new, untracked file. Next, I want to do git diff which will pop up a window (by default using vim) that looks something like this:

output of git diff

It shows that I added one new line in README.md. You’ll notice that nothing will show up for the untracked file! Now that I’m confident that my changes are what I want them to be, I’m going to do git add -A and then run git status -s again (which I have mapped to git s).

output of git add -A and git s

Time for a commit! If I have a longer commit message that I want to write, I will do a full git commit. More often, I will just use git commit -m to do it all in one line.

output from `git commit -m "extremely necessary hello_world script"`

Now, time to push it up.

output from git push

That might be all. However, like many developers, I often realize I have made a mistake. I like to pretend my mistakes never happened! Some people will just make a brand new commit with a message like “fixing typo”. Me? I pretend my typos never happened by making my changes, adding the file, then doing git commit —-amend.

git status -s, git diff, git add, git status -s, and git commit --amend

There are a couple of spots in this where I couldn’t get it all in one. So here’s the git diff that happened at the 9:34 timestamp:

git diff

Clearly I realized that I didn’t actually want “World” but for some reason wanted my name instead. After I added the file, this is what pops up when I do git commit -—amend:

output from git commit --amend

As you might be able to tell, I could also edit my commit message here! I also use amend if I have made a typo in a commit message or if I just want to expand on my initial, too short message. After amending (or rebasing), you will have to do a git push -f or a “force push”. Why? Because you are effectively rewriting git history!

git push -f

IMPORTANT NOTE if you are working on the same branch as someone else, be careful about force pushing. Consider using git push —-force-with-lease instead. And always make sure to let your buddy know that you are doing this.

That’s pretty much it! It might seem like a lot, but it actually gets pretty quick pretty fast as muscle memory kicks in. If you are interested in some shortcuts, here’s an example of what my .gitconfig sometimes looks like.

What’s your git workflow? Is there something you think I should change? Let me know!

I Was Interviewed!

in

I was recently a guest on the Virtual Coffee podcast! I talked about being a woman in tech, building community, and some random hot takes. I hope you enjoy it.

The official page for the podcast episode is here. The full episode is posted below (but definitely a nicer UI on the official page)!

Jennifer Konikowski - Hot Takes on Being a Woman in Tech
Virtual Coffee

Why We Should Stop Talking About Imposter Syndrome In Tech

in ,

Last week, my Virtual Coffee small group had a great conversation about imposter syndrome. I had wanted to talk about it because I had seen a request for an imposter syndrome channel in Slack and I didn’t think it would be a healthy choice. So I had some hot takes, which I am now bringing to my blog. First up, let’s define imposter syndrome. Merriam-Webster defines it as:

a false and sometimes crippling belief that one's successes are the product of luck or fraud rather than skill

Historically, this has been a phenomenon seen in high achieving women, which, as HBR noted, is likely due to the negative feedback that women regularly receive. So why does it seem like everyone in tech (particularly developers) have imposter syndrome now? Well, strap in, because I’ve got some hot takes coming your way!

1. People commonly use the term when referring to junior/early-career developers. This is pretty wild to me! If you are early in your career, you, by definition, have not really had any success as a developer! You are just getting started. I think Kim Crayton described this well in a talk she gave on mentoring at PyCaribbean in 2017 (quote is slightly paraphrased):

Learners do not have imposter syndrome. Imposter syndrome is people who have senior level skills and still don’t think they can do a job. Imposter syndrome is not learning. Learning is hard. Learning takes time. You don’t look at a baby who’s just been born and can’t flip over and tell them they’re suffering from imposter syndrome. No you’re not, you just don’t know how to flip over yet! That sounds absurd right?

With that in mind, maybe stop telling junior developers they have imposter syndrome. They are learning! They should not be expected to know everything.

2. Our job descriptions are absurd. I’m pretty happy with my current company (hey come work with us at Splice) because we don’t have 20 different technologies in our job description. HOWEVER: most job descriptions ask for multiple years of experience in both a backend language and frontend framework, Docker, AWS/Azure/Google Cloud, Kubernetes, GraphQL, etc. And you will see that on job descriptions that are not for senior developers. This is especially fraught for early-career devs, who regularly see non-senior posts that are still asking for all of those and 5+ years of experience which makes the job search seem hopeless. Let’s be more realistic with what we need versus what it’s more acceptable to learn on the job.

3. Interviews are an absolute nightmare. If you want to feel terrible about yourself, interview as a developer. At almost any level, you will be told by at least one company that you “aren’t senior enough” or “aren’t technical enough.” The way most companies do interviews also makes it feel way more like it is a personal failing on your part rather than just you and that job not being a great fit (which is actually the case). For example, I have had a broad swath of experience which has enabled me to jump into almost any codebase and be able to figure out (roughly) what’s going on and be able to make improvements. But I do not have experience building applications at scale. If we are being honest, very few people do. If you are at a large company that’s at that scale, you are likely part of a larger team and not making big architectural decisions. Or you might be at a smaller company and maybe have to scale from 100 to 1000, but not any further. Or, like me, you could have spent a decent portion of your career at B2B companies that do not have a ton of users. So why are we making people feel like they suck for just not being the right fit at your company? Maybe we should treat each other better.

4. To that point: talking about imposter syndrome makes it an individual problem. The problem is not with the individual! The problem is how we, as a community of developers, are treating each other. Instead of helping each other grow and lifting each other up, we are constantly putting others down to make sure it’s clear that we are the better developer. There are a ton of jobs! There is room for so many great developers. We do not have to compete in this way.

5. Is talking with others about imposter syndrome actually helping anyone? I think in some ways, it’s nice to feel like you aren’t alone! But when I see people with way more experience than me say that they are also struggling with imposter syndrome, it makes me feel hopeless. Like there is never going to be a point in my career where I can feel confident in my abilities. I can’t imagine what early-career devs are feeling when they see more accomplished developers also struggling. I think talking about it has made it way more of a thing than it should be. Everyone is sad sometimes, but not everyone suffers from depression. Everyone has times that they doubt their abilities, but not everyone has imposter syndrome. But we are at a point where, if you doubt your abilities, you have imposter syndrome. I think this is a bit absurd! It’s turning a normal human experience into a problem that you must solve.

Always happy to talk more about this and am also interested in any other hot takes!

Building a Donut Clone

in

I love Donut. In the past, it has done a great job of connecting me with coworkers or with new people large networking Slack. However, when I went to go add it to a new Slack that I started, I noticed that it will only pair up to 24 users per round for free. The group I run has 175 people in our #coffee-buddies channel. How much would that cost me? Maybe it’s not too much… OH $399/month??? I can build something that does a good enough job. So I built Slack Pairs.

Slack Pairs is a super basic Rails app that just needs free-level hosting on a platform like Heroku. The most challenging part of the setup is actually setting up the new Slack app and making sure it’s paired correctly. The easiest way to do this is to create a new channel in your slack instance, add one other person, and then run the task. If it sends you both a message, it’s set up correctly! Then you just change the channel id to the correct one and you are off to the races.

I would love to make this app more extensible and not require a fork or code modifications. I think that addition would be relatively simple, I just haven’t had time. I’m open to submissions if you have any cool ideas to improve it!

Don't Tell Me I Have Imposter Syndrome

in

The article about Mailchimp that I mentioned in my last post was finally posted last Monday. This was fun:

Jennifer Konikowski, Mailchimp's only female engineer during her tenure from 2011 to 2012, told Insider that her managers criticized her "tone" in a performance review and that a male coworker complained about her simply for disagreeing with a different coworker.

Unbeknownst to Konikowski at the time, her managers had explicitly conspired to get her to quit, according to Jared Van Aalten, who said he was in the room during their conversation. The managers worried firing Konikowski could be perceived as sexist, so they discussed giving her projects outside her skill and comfort zone to make her look bad and avoid suspicion, Van Aalten told Insider.

Konikowski quit, but her managers — both white men — were eventually promoted to senior management. Van Aalten said the promotions troubled him because one of those managers had called him a Nazi, despite knowing he's Jewish. Multiple former Mailchimp employees also said that the manager questioned whether people with Down's Syndrome were "real people" because they inherit an extra chromosome.

It’s a little off: I only had one manager (Brandon Fouts) and the other person (Matthew Grove, the one who said the gross comments) was not a manager at the time and just a year senior to me. Another oddity is that I wasn’t technically the only female engineer: there were frontend engineers at the time, but they were totally separated and referred to as designers. Somehow I only realized this recently and, every time I see this, I feel like I’m erasing them. Overall, it was a solid article and I went on a whole tweetrant about it. I think the biggest thing I’ve learned since the article came out is this: despite leaving on what I thought was a positive note, Matthew disparaged me to other people on the delivery team for at least a year after I left. People who didn’t know me heard my name in a negative context. I know there’s been anger from me recently, but I didn’t say anything against Mailchimp for years. Until a month ago, I thought Brandon had been a good, supportive boss. He had actually apologized to me when he had cc’d HR after Matthew reported me for telling Van he was wrong. When I asked not to share an office with a different coworker who creeped me out, he seemed to support that and did not move me back into the office. I blamed everything that happened afterward on Matthew. I didn’t realize that Brandon and Matthew colluded.

This whole situation has me revisiting the article “Stop Telling Women They Have Imposter Syndrome” by Ruchika Tulshyan and Jodi-Ann Burey in HBR. Definitely go and read the entire thing, but here is one (of many) parts that really jumped out to me:

Imposter syndrome took a fairly universal feeling of discomfort, second-guessing, and mild anxiety in the workplace and pathologized it, especially for women. As white men progress, their feelings of doubt usually abate as their work and intelligence are validated over time. They’re able to find role models who are like them, and rarely (if ever) do others question their competence, contributions, or leadership style. Women experience the opposite. Rarely are we invited to a women’s career development conference where a session on “overcoming imposter syndrome” is not on the agenda.

The label of imposter syndrome is a heavy load to bear. “Imposter” brings a tinge of criminal fraudulence to the feeling of simply being unsure or anxious about joining a new team or learning a new skill. Add to that the medical undertone of “syndrome,” which recalls the “female hysteria” diagnoses of the nineteenth century. Although feelings of uncertainty are an expected and normal part of professional life, women who experience them are deemed to suffer from imposter syndrome. Even if women demonstrate strength, ambition, and resilience, our daily battles with microaggressions, especially expectations and assumptions formed by stereotypes and racism, often push us down. Imposter syndrome as a concept fails to capture this dynamic and puts the onus on women to deal with the effects. Workplaces remain misdirected toward seeking individual solutions for issues disproportionately caused by systems of discrimination and abuses of power.

I’ve been thinking about this a lot. I’ve had some supportive coworkers and a couple of decent managers. But I’ve also had this happen. And I’ve had a manager and HR have a talk with me about refusing a doughnut (not joking). I’ve had a manager tell me I was not performing at level during a time when my husband was recovering from seven broken bones (after having previously gotten positive feedback). Then that manager told me I shouldn’t ask any questions unless I had fully documented everything that I had attempted. At a few points during that position, I actually cried at work. I felt worthless. I felt like I couldn’t do my job. I didn’t know why anyone would ever hire me again because, clearly, I couldn’t code. When I was reading this article, I felt both sad and vindicated. I often don’t have a lot of confidence and there are distinct reasons why. It’s not imposter syndrome. It’s a past of regularly having my abilities being questioned. I know I’m not the only one. So stop telling women they have imposter syndrome.

Why I Didn't Speak Up Earlier

My former employer is having a very bad week. I worked at Mailchimp from March 2011 to November 2012. I wrote an anonymized version of the latter part of my experience already. I talked to the reporter for the Business Insider story, and it’s likely to come out soon. I opted not to be anonymous. During this process, he asked me two questions that made me think and want to write a bit more about my own perspective.

  1. Did you talk to your coworkers about salaries?

  2. Do you have any documentation of reports you made?

The answer to both of those is no. I’m going to dig into each one by one.

I grew up being told that you should not discuss salaries. I even thought it was illegal, or I could get in trouble for it! Even a few years ago, I was onboarding for a job and the HR person said pay was something we could not talk about, other than to our manager. Just in case you don’t know: in the United States, you are legally protected when discussing salaries with coworkers. It is in your best interest to discuss salaries with coworkers. Keeping quiet about salaries increases pay inequality. However, I was 24 when I started at Mailchimp, it was my second job out of college, and I had no idea. I was the only woman in engineering and I was paid $45,000. The excuse for the low pay was that I didn’t have any experience… but the role was for a deliverability engineer, which is a role that only exists at email service providers and internet service providers. There are still not many of those and there were even fewer in 2011… especially in the Atlanta area. The other guy in my department only had one year of experience, only at Mailchimp. I had an engineering degree and almost a year working in IT at Home Depot. Given that I know know that entry-level support made $35,000, I do not doubt that I was the lowest-paid engineer by far. I wish I had talked about salaries with my coworkers then and even in later roles because it took me years to realize that I was being underpaid. I think another reason Mailchimp gets away with this is that, for many people, it’s their first professional job and it’s just great to have healthcare. But given how much money Ben and Dan have made off the backs of their poorly-treated support team, I think they could have easily paid their employees a bit more.

As far as documentation, there is no documentation from me because I never made an official report. One of my coworkers would lift his shirt a bit in meetings, scratch his stomach, and stare at me. It was unnerving and very creepy. Why didn’t I report that? Well, everyone was aware he was creepy. I was young and we were all “friends”. Why would I report a friend? Plus, everyone knew he was a creep, so obviously, he wasn’t doing anything wrong, right? Looking back, I think it felt like someone else should have come in to fix it, but there was no one else. All I felt I could do was ask my boss not to make me share an office with the guy. One day while we were all (at least 20 people) eating lunch, another guy on my team decided to start debating what makes a person. Then he posed the question, “Are people with Down’s Syndrome really people? They have an extra chromosome, so if DNA makes a human, do they count?” I was pretty dismayed, mentioned that was inappropriate, but didn’t do anything beyond that. There were managers in that room; if it could be acted on, they would surely do something. That man is now a manager at Mailchimp. He is also the person who made it so uncomfortable for me to work there that I moved up to Boston with the first job I could get and a full 6 months earlier than I planned.

So why didn’t I speak up earlier? Like many people, I felt like Mailchimp had an outsized influence on my career. I was worried that, if I said anything against them, it would be a black mark against me. Even after I moved states… twice. Even now, I was hesitant. It also felt like, on an overall scale, it wasn’t that bad, right? I was never propositioned or assaulted, A+ for that. And yet… in all the companies I have worked for, Mailchimp still stands out as the place that feels the most problematic (other than the super tiny vegan startup that shall not be named), even almost 9 years later.