DEV Community: Karen Carter

"Does it get easier?" Yes, but Also No...

Karen Carter — Thu, 15 Jul 2021 04:30:00 +0000

It's complicated...

"Does it get easier?" I see some form of this question asked a lot in beginner programming groups. I always struggle with how to answer this honestly and clearly, because the truth is not that simple. In some ways it does get easier, but in other ways it is almost always going to be difficult if you are advancing in your career. If you are a programmer and your job is easy for years on end, the most likely explanation is that you're in the kind of dead-end position that people try to avoid, not the kind of position people dream about when they think of becoming a developer. Most likely you are not getting better at being a dev, not working with new tech or solving new kinds of problems, not being given more responsibility, etc. etc. etc.

I've seen some pushback from other newbie programmers on the idea that it could remain difficult past the initial learning stage. Notably I have never once seen somebody who's already working in the industry try and argue that. Some claim it's gatekeeping, others will say "if it's so difficult why don't you go do something easier?" Now I'll be the first to admit that there is way too much gatekeeping in this industry, and I've experienced plenty of it, including in interviews where my geek creds were being checked in the name of "cultural fit". But talking about how programming remains hard for your entire career is not gatekeeping: it's trying to let people know what they're signing up for.

Difficulty is not a value judgement.

As for the second argument, "why not go do something easier?", this, of course, is a logical fallacy (not to mention a question that reveals more about the asker's attitude than the person they are asking). Difficulty is not a value judgement. Just because something is difficult that doesn't mean it isn't fun, worthwhile, fulfilling, or any other good thing you can think of. There are plenty of careers that we commonly accept as both difficult and worth doing: medicine, law, engineering, rocket science, whatever. And I think many would accept the idea of parenting being something both difficult and worthwhile. So there is no reason on earth why the same should not apply to programming. In fact, there are many of us that choose this career because it is so challenging: the difficulty and always-changing nature of the work is a big part of the appeal. There is also another big reason many want to get into the field: it is seen as a lucrative career. Thinking about it logically, if it were so easy, why would it pay so well?

That said, again, there are some things that get better. Many folks struggle a lot in the very beginning because they have to learn a different way of thinking in order to program, and once they have developed that new, logical mindset it gets a lot easier. As your problem solving skills improve, it will take less time to solve the same or similar kinds of problems. After you've worked with a given language/framework/code base for awhile you won't have to look things up as often, or when you do need to look them up (you do NOT need to keep everything in your head, just know where to find it) you'll know exactly where to look, including for examples of similar functionality you've built in the past, so it'll be both faster and easier. Past successes also tend to lead to more confidence in the future: once you've proven you can, in fact, do hard things, then doing more hard things in the future seems less daunting. And of course if you're learning in a very intensive course or bootcamp, once you start working that sort of intense drinking-from-a-firehose feeling is not going to be there most of the time (although it can still feel pretty insane whenever you start a new job or project or get new responsibilities... but at least then you're getting paid for the insanity!). These kinds of things do legitimately get better.

Image by Gerd Altmann from Pixabay

What doesn't get better? For starters, you will never be able to stop learning if you want to stay in the industry. There is effectively no way to "master" anything in the sense of learning everything there is to learn about something and then being done with it. Even if you stay in the same tech stack, there are always new versions coming out. Not only are there bug and security fixes you will want and need to take advantage of, but at a certain point you will be forced to upgrade as hardware/OS/framework/programming language versions become obsolete. Sometimes the tech you're working with will even get completely discontinued, so you will need to learn an entirely new way of working. A very recent example is Flash being forcefully discontinued at the beginning of the year. All those programmers and users had no choice but to move to something else.

In addition to this, the kinds of problems you will be expected to solve will only get harder and more complex as you advance in your career. Not only in terms of business needs (a company is unlikely to continue solving the exact same problem in the exact same way over and over, after all), but also in terms of responsibilities. A junior may be told what the user interface should look like and what kind of approach to take to program the back end, where an intermediate dev will be left to figure most of it out on their own (with supervision and assistance from more senior devs), but a lead dev will have to come up with the entire architecture for the project. "How to program" is really just the start, even if you specialize. Database schema design, user experience, accessibility, architecture, networking, scalability, security... The list goes on. There is no way you're going to know all of this coming out of a bootcamp or even from a 4 year degree plan. But if you want to get promotions and more money, you will need to continue learning and improving.

Image by Arek Socha from Pixabay

Learning to program is not a get-rich quick scheme.

I write this not to be discouraging, but because I want people to understand what a career as a programmer really looks like. Particularly right now, when there are a whole lot of people making a whole lot of money selling the dream of becoming a dev, many of whom are quite frankly selling the modern-day equivalent of snake oil, I think it's important for those of us already in the industry to be clear about what it's really like. Learning to program is not a get-rich quick scheme. It takes quite a lot of both time and effort to start, and the effort part is never going to go away. Time, arguably, becomes less of an issue; professional development should be on your employer's dime once you get a job. Granted there are plenty of (in my opinion quite toxic) workplaces and devs that promote the idea that you need to program non-stop and have no personal life in order to stay relevant; that is thankfully not actually a hard requirement, unlike the effort. Either way though, if you are turned off by the idea of constant learning and ever-increasing difficulty of job duties, this is not the career for you.

It's hard, but you can do hard things!

On the other hand, if that sounds amazing to you, like it does to me and many other devs, come join us! It's hard, but you can do hard things! It's (usually) fun and interesting and it's rarely boring. Plus you get to see people look super impressed when you say what you do for a living. A++++, five stars, would highly recommend. I can't imagine doing anything else for a living, even if I am well into in the 4th and final stage of a dev's life:

Newbie Developers: "I don't know anything!"

Junior Developers: "I know everything!"

Senior Developers: "I know nothing!"

Veteran Developers: "I know nothing about everything!"
— Casper Beyer (@caspervonb) April 11, 2018

How to Land Your First Dev Job: Develop Yourself, Market Yourself

Karen Carter — Fri, 07 May 2021 01:14:00 +0000

Image by magnetme from Pixabay

In the coding and tech groups I'm in, I see the same question asked over and over by folks who are just learning to code, finishing up a bootcamp, degree, or other training program, or who have been looking for that first job for awhile and not having any luck: "what do I need to do to get my first dev job?" There's a whole ton of info out there on this topic, but it's scattered all over, so I thought I would gather together the best resources I've come across and share them, along with a bit of context, to try and help everybody struggling with or just plain wondering about this.

There are a lot of things you can do to improve your chances of finding a job and hopefully shorten your job search. They are broadly divided into 2 categories: developing yourself and your skills, and marketing yourself and your skills. Note that you don't need to do everything on this list, nor do you need to do it all at once. This is an "every little bit helps" kind of thing. Just keep working away at it until you finally land that first job. At that point you can absolutely back off: there's a huge bottleneck at the entry/junior level, so once you have a few years of experience subsequent jobs won't require nearly this much effort. At that point your actual work experience should start to speak for itself.

Before you continue, I strongly recommend reading this excellent overview of the dev job search. It covers many of the same topics as this article; I list additional resources wherever I can to give an even clearer picture of what each of these bullet points requires. And then:

Develop Yourself

Get an internship, if you can. Real-world experience is king.
Continue learning and show off your new knowledge in your portfolio. Check out the free for developers list for help with hosting, APIs (front-end devs, this is a GREAT way to build some cool projects that consume an API), and all sorts of tools to help you build projects for free.
Improve your git skills and get all of your portfolio projects up on GitHub/GitLab/Bitbucket. Git is mandatory if you want to be a dev.
Contribute to open source projects. Read up on how and where to contribute. Find smaller projects that need someone with your skills on a site like GitPals or start your own project with other devs.
Participate in hackathons. You'll learn a lot AND have something to brag about on your resume/LinkedIn. It's a win/win scenario.
Volunteer to build/improve websites for local non-profits, or look for volunteer opportunities online.
Practice for coding interviews. Hackerrank is often used directly in the interview process so you absolutely need to familiarize yourself with it. Codewars and similar sites are great, too, but less likely to be part of the interview process.
Read Cracking the Coding Interview (although if you're strictly front-end this isn't going to be as useful).
Google your preferred languages plus "interview questions" and study up.

Market Yourself

Improve your resume using this series of Tweets or the book linked from them.
Improve your LinkedIn to make sure you're highlighting the most important items.
Broaden your job search by using targeted job boards in addition to LinkedIn, Dice, Indeed, etc. For both this and LinkedIn info refer back to the article I linked at the start of this post.
Networking. It's absolutely crucial, but everyone is confused on how to do it. This article about how one woman networked and raised her profile so much after completing a bootcamp that she got multiple amazing job offers is one of the best concrete descriptions I've seen.
Attend conferences and take advantage of the networking events that are part of them. Right now most conferences are still online and free or very cheap, so take advantage while you can!
Write blog posts or articles about your learning process, cool projects, job search, etc. and publish/link to them on a variety of platforms. dev.to, Medium, Twitter, Instagram, and of course your LinkedIn feed. The point is to raise your profile, so do that however you can, even if it feels icky. It sucks, but it's necessary in this insanely competitive job market.
Get involved in local and/or online developer groups. Facebook has lots of specialized dev groups, Instagram and Twitter have whole tech subsections, then of course there's Reddit, and the list goes on. Just get involved. By giving back to the community you will raise your own profile. Fellow female devs, be sure to check out Women Who Code for online and (some day) in-person events, conferences, a job board and newsletter, a YouTube channel with incredible career development content, and more.
Volunteer to speak at conferences or give presentations at developer group meetings. This is one of those things that is insanely scary to a lot of us, but it means there's a lot of opportunity for those willing to put themselves out there. The article I linked about networking has great info on speaking at events, too.

Image by Gerd Altmann from Pixabay

TL;DR

Don't stop learning, keep improving your portfolio, resume, and LinkedIn, network network network, practice for interviews, get involved in the dev community, and get your name out there as much as you can. It is a lot of work and takes a lot of time, so the sooner you start on it, the better. Many of these activities can be started when you first start learning, far before you're at the job search stage.

Above all, don't get discouraged by a long job search (a year or more) or a lot of rejections. That is absolutely normal in the current hyper-competitive entry- and junior-level dev job market. If you can hold out until you get that first dev job, job searches will get much easier going forward. Don't lose hope.

Git. The WHAT and WHY Edition.

Karen Carter — Thu, 03 Sep 2020 22:23:00 +0000

Lately I've seen a lot of new/aspiring developers talk about difficulties learning git. I was confused at first, because there are approximately a zillion git tutorials out there. But then I started really looking at what people were saying AND what all those tutorials contain. The problem is most tutorials start out with "here are a ton of git commands to memorize", and this is not where people are having problems. People are having problems with "what is git, why should I learn it, and what does it look like to use it in a real-life project?", and those questions are largely not answered in all those millions of tutorials. So at the risk of redundancy, I'm going to attempt to address these questions in Yet Another Article About Git.

Why git?

First, I want to make it clear that

if you want to be a programmer, any kind of programmer, you need to know git. You just DO.

This is the short version of the answer to "why should I learn it?".

The medium length answer is that git has become THE preeminent version control software since its release in 2005, and particularly since GitHub came about in 2008. This StackExchange question purports to show the change in number of repositories over time, with last count being 72% git, if you click through to the source of the data. And in the last StackOverflow developer survey, "Of the professional developers who responded to the survey, almost 82% use GitHub as a collaborative tool". This means the number of respondents using git is even higher, because GitHub is just one option for using git (more on this later). For context, the second most popular technology on their survey, JavaScript, comes in at only 67.7%. So git is probably the single most widely-used bit of tech for developers, above literally anything else. If you want to work on or use open source projects, if you want to work with someone else or FOR someone else, at some point somebody is going to point you to a git repo that you are going to need to be able to Do Stuff with.

The long answer is all the stuff about version control and tracking changes and how much easier it makes large projects with multiple people and why git is easier than the alternatives (no, git is not the only version control software, yes, I have used others including CVS, Subversion, and Perforce because I'm old enough that git didn't exist when I got started, and I still prefer git, as do many others judging from the overwhelming popularity of it and the incredible speed with which it took over), but when you're just getting started you're probably not worrying about any of that. The thing to focus on is that this is something that you need to know if you want to be a programmer. Git's extensive use by other programmers means that you are going to look really foolish in an interview or even a conversation with another programmer if you say you've been programming for X number of years and you don't know git, or if you're a CS student who thinks they're going to get a job out of school but "doesn't want to learn git" (which is an actual thing that one of our interns heard in recent years)... Just learn git, OK?

What is git?

Now that you are hopefully convinced that knowing git is right up there in importance with knowing whatever other languages or tools you're currently working on (even for you, front-end web developers! Git should really be right on the top of that list with HTML, CSS, and JavaScript), I'll try for a simplified version of "what is git?" Git is software that lets you track changes to a collection of files (AKA a repository; it sounds fancy but it's literally just a collection of files) over time. This is not so important when you are just starting out and working on tiny personal projects, but the bigger the project and the more people working on it, the more vital it becomes. You tell the software to save the current state of the collection of files by adding and committing. Then if you screw up later you can roll back the code to a former commit; essentially this reloads the files to an earlier version when things were working. You can also create a branch, which acts like a separate copy of the collection of files; you can then manipulate those files without screwing with the original copy. Typically you do this when you're developing a new feature on an existing project, if you are doing something very experimental and you think it might break stuff, or if you're working with someone else and you'll both be making changes at the same time. The branch functions as a set of commits that you can easily keep or discard according to how things are going. There's much more to it, of course, but this is the basic stuff you need to understand to get started. All these things can be done all by yourself, on your own computer, without a GitHub or any other account. So that is git on a very basic level.

What is GitHub?

GitHub is by far the most popular place to store git repositories online, on someone else's server. It has a lot of other cool features, but for the purposes of learning git, that's all you really need to know. It is not the only place to store git repositories (GitLab and Atlassian's Bitbucket are the other popular commercial options, but you can also set up your own server, which many companies do), and it's not actually necessary to start using git. You can use git on your computer and it will track all those lovely changes and branches all on its own. The reason people use GitHub/GitLab/Bitbucket is primarily to 1. create an off-site back-up of their work and 2. share their files so others can contribute to their project, or critique it, or just plain use it. Git itself, running on your computer, needs to be configured if you want to back-up or share your work. This is what people mean when they talk about remotes. You will need to tell git where the files should go when you push (the command to get your changes saved on the server), or where they should come from when you pull (the command to retrieve changes from the server and save them on your local machine). Luckily, this setup step usually only needs to be done once, and then you are good. So you can do it and forget all about it until you get a new computer and/or job.

Conclusion: Don't Get Intimidated

The final thing I want to address about git is that, while git can get really, really complicated, and it can be intimidating to go to one of those tutorials and see huge lists of commands, the reality is that the vast majority of programmers are not actually git wizards, and they use a tiny fraction of all the available commands. As usual, XKCD has addressed this with a great comic:

So please, don't get intimidated by the enormity of the tool. 97% of the time the only things you will be doing are checking the status of your code, pulling, pushing, adding, committing, and branching. 6 commands. Really. Another 2 percent of the time you'll be creating pull requests (asking someone else to bring the changes you made in your branch of a project into the main branch of the project, which is usually done in a GUI anyway) and/or merging (doing the actual bringing in of changes made in one branch into another branch). The remaining 1 percent of the time, when you need to roll back a commit or discard your work before committing or start a brand new project (because in the real world projects are big long things, so you're not starting a new one every week) or when some other unusual situation comes up, you can use Google or a git cheat sheet or one of those cool mugs. To borrow Don Norman's concept, *the knowledge exists in the world; you do NOT need to keep it in your head. * The amazingly useful site Oh shit, git has the answers to how to get yourself out of many common messes. And of course, like the comic says, if all else fails save your work off elsewhere, delete the files on your local machine, and download a new copy from the server.

I'm a lead dev, I'm in charge of code reviews and keeping the codebase clean, all these repos that hold the code for our apps are my babies that I protect with my (professional) life, so I use git every day... But the above 100% applies to me. I've taken git classes that taught the more advanced features, I've read the docs... And I still have to Google them any time I actually need them, because it's so rare that I can't remember the commands off-hand. I don't even use merge from the command line anymore because we have our own GitLab instance and I like the GUI better due to the way it shows changes. I also start new projects from the GUI because at the same time I like to add a description and the project icon and set permissions and protect branches and......., so I also don't git init anymore (just a nice simple git clone after it's all set up). Since our team is so small I prefer to keep all the history from merging, so I don't even bother with rebasing.

I hope this simple overview and explanation will bring git down to earth for new developers. It's something you need to know, but it really isn't all that scary in practice. You can do it! I am planning to write another post soon about some real-world scenarios and the commands used, as well as explaining a couple of different branching models (which are essentially a way to organize/regulate how you use git within a group of developers), since this is another git area that seems to be under-explained. If you know of any other areas that are under-explained, please let me know! Git is such a ubiquitous tool, nobody should need to struggle learning or understanding it.

Tech Jobs Outside of the Tech Industry

Karen Carter — Mon, 13 Jan 2020 06:22:00 +0000

I wrote this post in January of 2020, but it's still very relevant today. I hope more people will consider looking into tech jobs outside of the tech industry, as there are a lot of overlooked opportunities out there.

This is one of those things that I never gave a second thought to. Growing up in New Mexico, there were more tech jobs in government than in any other industry. White Sands Missile Range, Sandia and Los Alamos National Laboratories, not to mention state, county, and city jobs. My dad plus many of my friends' parents worked in tech for the feds. While there are more and more tech companies moving in, government is still a major player in the area and probably always will be.

But that was just my experience. In many areas the tech industry itself is much more prominent, and of course those jobs are the ones that get all the press. You rarely see articles about working as a software developer at the IRS, or something like that. It's always Google or Amazon, a start-up, etc. To many people, being a software developer is synonymous with working in the tech industry.

So when Jenny Chan, who founded the Women in Web Dev community, contacted me to ask if I'd do an interview for the Women in Web Dev blog, after reading a random comment I'd made about working as a software developer but not in the tech industry, I was initially surprised. I really shouldn't have been, but I was.

Anyhow, you can read the interview here. I was very happy to help raise the profile of government jobs, and that Jenny is planning to publish more interviews with devs who are working outside the tech industry. There are so many different kinds of opportunities out there for programmers to work in all different fields, and I think it's really important for people to realize that. Non-profits and healthcare are other fields you might also hear about, but honestly practically any field you can think of will need software developers. My co-worker's brother is a dev for an athletic wear company. One of our former students got a job as a dev working for an airline. Tech, and programming, are everywhere.

Also, as a bonus if you've read this far, here are some more things I love about my job (the list was really getting too long so I had to pare it down a bit!):

I love seeing how our work directly helps our co-workers (and thus the constituents of the state of New Mexico). One of my favorite memories is the time one of our users told us that the new app we created helped her do in one hour what used to take 8 hours. There's no wondering if we're creating something useful around here... We know our apps are going to help people and make their lives better.
I love constantly learning new things, both technical and procedural. The department has SO many different areas of responsibility, and new ones are being added all the time. I've learned about egg dealer fees, petroleum lab tests, dairy sampling procedures, all kinds of stuff, not to mention all the different technologies required to create apps for all those different things.
I love being up-to-date with technology. Government software development has a reputation for being behind the times, but not here. Even the bleeding edge isn't enough for us, sometimes (looking at you, progressive web apps... They're great for consumers of information, but totally inadequate when your users are producing information).
I love being part of an organization that encourages learning. Since NMDA is part of NMSU, we get 6 free credit hours per semester. I earned my masters while working here, nearly for free, and still regularly take classes. I'm signed up for a block chain class this coming semester, in fact. [That class got cancelled, but I did just finish auditing an applied machine learning class!]
I love seeing a news story about an NMDA function or going to the gas station and seeing the NMDA sticker on the pump and thinking "I wrote an app for that!"
This is totally silly, but I love seeing this sign when I'm driving on the interstate. We get our own sign, how cool is that!

Basically, I love my job. So much.