Developer, Rabble-Rouser
Ruby/Scala Developer, PyLadies Boston Founder, Rabble-rouser
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!
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.
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.
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:
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).
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.
Now, time to push it up.
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.
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:
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:
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!
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 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)!
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!
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!
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.
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.
Did you talk to your coworkers about salaries?
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.
I’m currently working on a PHP project that had a mix of camelCase and snake_case for variables and methods. We had recently started using PHP-CS-Fixer on the project and, unfortunately, there was not an existing rule to make this kind of change. So I decided to write a variable case fixer myself! Now: this is inherently risky. Instance variables in PHP are called using $this->variableName, which is really similar to how you call a function. Those could also be defined above the constructor like private $variableName and that would be fixed with a fixer like this, but any call site would not. So there’s some of the risk 😅. There are also predefined variables in PHP that we would not want to update. Ok, let’s get started!
Since I was using an existing project, I did not have to worry about getting each file and was able to trust PHP-CS-Fixer to parse each file and get me the tokens. The hardest part of this was actually figuring out how to pick out the tokens. So all this does is check to see if the token (smallest block of code) is either of the two variable types and not in the list of predefined variables.
foreach ($tokens as $index => $token) {
if ((T_VARIABLE === $token->getId()) || (T_STRING_VARNAME === $token->getId())) {
if (in_array($token->getContent(), $predefinedVariables)) {
continue;
}
$tokens[$index] = new Token([$token->getId(), $this->updateVariableCasing($token->getContent())]);
}
}
That is actually the bulk of it! updateVariableCasing just takes the configuration and then calls whatever function we need (ie camelCase if configuration['case'] is equal to camel_case. The functions to change case were found somewhere on StackOverflow. Overall, this works very well! The only places we ran into problems were where private variables were defined at the top, converted there, but then not converted when called in the code (as $this->variable_name). Something to keep in mind if you decide to implement something like this in your project.
I did put up a PR to add this rule to PHP-CS-Fixer, but I think they were reluctant to add it since it’s not safe and I don’t have a ton of extra time to keep trying to get it in.
I decided to give VSCode a chance again and decided, hey, if I'm setting up an editor from scratch, let's make it fun! I searched around and found the following extensions:
The colors they each defaulted to were... fine. But I needed ✨rainbow✨. So here are my settings:
End result is this for Bracket Pair Colorizer and Indent Rainbow (Rainbow Tags looks very similar):
And this is what Rainbow CSV looks like:
I did try Rainbow String, which was pretty cool! But it would sometimes rainbowize more than just strings and then I couldn't take advantage of the syntax highlighting. Overall, I can't recommend that one, even though it is pretty fabulous.
I've had a lot of jobs, and, over the years, I've been refining my list of questions to do my best to ensure that the company I'm interviewing at is a good fit for me. I just went through the job search again, and asking all of these questions helped me determine that Test Double was the right place for me. I cannot stress enough the importance of asking questions in the interview. When I was first out of college, it sounded like I needed to ask questions to impress the interviewers. The truth is that interviewing is a two-way street, and asking questions is how you can find out if the company is the right fit for you. Not asking the right questions is how I've ended up at a lot of places that just weren't right for me in the long term. You should feel free to either use this list verbatim or use only the questions that are relevant to you and your needs. I also listed additional resources at the bottom. I also keep this list up-to-date on Github.
How does the engineering culture differ from the overall company culture?
Can you give me an example of a mistake you've made here, and how it was handled?
How often do you pair?
When something goes wrong, how do you handle it? Do devs get shamed for breaking the build?
How are disagreements solved - both technical disagreements and other kinds?
What happens when personalities clash?
How flexible are work hours?
What tools do you use for remote collaboration?
How do they work together and ensure good communication and collaboration?
Can you tell me about what I can expect from the interview process?
How many hours do people work in an average week? In your busiest weeks?
How often are there emergencies or times when people have to work extra hours?
Who sets deadlines and what happens when people fail to meet them?
Can you walk me through your development process, from a ticket or task to code on production?
What checks and balances are in place to make sure people don't make big mistakes or repeat mistakes
What is your build process like?
How does this team plan projects and create deadline estimates?
What is the median age that an issue will be open for?
Who is responsible for doing deployment? How often do you deploy?
Is there a written roadmap all developers can see? How far into the future does it extend? How closely is it followed?
How often do you have meetings? Are there any scheduled/standing meetings?
What’s your approach to technical debt?
Describe your deployment process – how do you find bugs in your team’s code?
Do you have a QA team?
Do you have style guides?
How does engineering work get assigned?
How are technical decisions made and communicated?
Would I need to be on call? How often? What is the SLA? How often do people tend to be paged? How often is it a real emergency?
What does your stack look like? What languages/tools/etc. do you use?
What sort of growth is available for senior engineers?
How does your company support the growth of junior engineers?
Are there times of the month, quarter, or year when the team is most busy?
Tell me a little bit about your team onboarding process.
How is employee performance evaluated?
Is there a budget for employee education/training/development/etc.?
Is there support for conference attendance?
What accomplishment are you most proud of since joining the company?
What size is the team?
How many total development teams?
How much vacation do people get? Sick leave? Are they combined or separate?
Do people check in when they’re on vacation? How often?
The Cut: Best Questions to Ask in a Job Interview
Julie Pagano's Job Search Retrospective
What is the most important thing in your life? If you say Slack emojis, then you maybe have a misplaced sense of importance, but also, I understand. One of my current slacks has over 4,000 emojis. I wanted to pull them all down so I could add the ones that aren’t inside jokes to another slack… but how? There are a number of JS scripts out there that say that they will do this but I think Slack has since updated the JSON that they send so those didn’t work anymore. Being a rubyist, I wrote a parser for that JSON to export all the emojis. Downside: I still had to download all the JSON files. If you are more ambitious than me, I’m sure there is a way to do that via JavaScript fairly easily.
Open up developer tools then the network tab.
Filter by XHR or just search for emoji.adminList (might have to reload the page).
4. Copy and paste into a file called emoji#{number}.json with #{number} being the file number.
5. Keep scrolling down and keep copying and pasting and creating files.
6. Download the script into the same directory
7. Run script like this: ruby download_emojis.rb NUMBER_OF_FILES_CREATED Note: NUMBER_OF_FILES_CREATED should be replaced with however many files you created. It defaults to 10.
8. The files will be created in an emojis folder with the name of the emoji as the file name.
I have basically written this post before. However, I recently got the following email:
I'm an electrical engineer looking hard at web development bootcamps. How was your experience transitioning from engineering to software? Did you do a bootcamp, self study, or something else? The bootcamp is full stack and looks pretty comprehensive, but I'm just so nervous about such a big commitment.
and oh boy did I feel like I had more to say. I ended up writing enough that I felt like maybe I should go ahead and put it in a blog post as well. I’m going to add some annotations to this to make my intentions even more clear. Here goes (again):
I actually found transitioning from engineering to software to be fairly easy. Hiring managers are more likely to take you seriously (versus if you had a philosophy degree [1]). Granted, a lot of what I’m going to say is assuming you currently have a job. If you do not, a boot camp is not a bad idea. If you do, a boot camp is 100% not worth it [2]. I’ve heard many people who went to boot camp say that they valued it for giving them projects and deadlines but that they basically taught themselves. If you require external deadlines to learn, that’s about all a $15K boot camp is going to give you. Here’s what I would recommend:
1) Find a language that does what you want to do. If you want to do more data-focused work, choose python. Web development? Ruby. Systems programming? Rust or C. There are a lot more (so. many. languages), but you want to make sure it’s common enough that there are resources and you can get a job. Then learn it. Not completely, but enough to get started on projects.
2) Practice and get feedback. Exercism.io is perfect for this. You can do exercises in any language and, once you’ve submitted your solution, get feedback from mentors and also give feedback to other users.
3) If possible, code at work. Automate tasks that you do regularly. When I worked at MailChimp, I was able to write scripts to automate log parsing. Again, this might not be possible! But think outside the box, because if you can do this, it can go on your resume under your current job.
4) Have one or two good projects on Github. These are projects you want to show a potential employer to effectively prove you can code. It doesn’t have to be huge! If you wrote a great script that is really useful, that counts. If you wrote a web app, that counts. Just get some friends to review the code, maybe do a bit of QA on the app and open up issues for things you want to fix.
5) Another alternative (or in addition if you are feeling extra ambitious) is to find an open source project or two that you find interesting and contribute. In many ways this is better because it means someone else will have reviewed your code. But it’s often harder to find a project that you feel confident putting up a pull request.
6) NETWORK. Oftentimes bootcamps tout this as a benefit of the bootcamp, but really they just send you to local meetups. You can do this on your own! Meetups are almost always free.
7) Review some basic CS concepts. I hate that people interview this way, but enough people do that it’s worth your time to do a small amount of studying. This video series by Rob Conery covers most of what you need to know, but you can also do a lot of googling because everything is out there.
8) Just start applying to jobs. Even if you don’t feel 100% ready. You’ll be applying for junior positions and no one interviewing you should expect you to know everything (or even most things). You might get questions that feel that way, but they are just trying to gauge your knowledge level. Or maybe they are assholes! But then you don’t want to work there.
Annotations:
1. There is nothing wrong with a philosophy degree! One of the best developers I know has a degree in Classics. However, many developers still think that having a liberal arts degree means you are less technical and will have more trouble as a developer. This is not true, but you might encounter it.
2. I know this is a strong opinion. And it’s just an opinion. I know great developers who went through boot camps. However, I am quite certain that they would be great developers without the boot camp.
I have a mild obsession with the Flyers’ new mascot, Gritty.
So imagine my pure delight when one of my coworker’s shares this work of art by Adam Kuhn, done entirely in CSS.
See the Pen Pure CSS Gritty by Adam Kuhn (@cobra_winfrey) on CodePen.
This is the most beautiful thing I’ve ever seen and I’m so happy that CSS has the capability to do this.
Last year, I volunteered with TEALS, working with a local teacher once a month who was teaching the AP CS class. There was some extra time at the end of the year, so my teacher requested that I put together some materials to teach the kids something new. Since I was teaching myself Rust at the time, I decided to write a guide specifically aimed at high school students who have learned some Java but are now interested in Rust. I was heavily inspired by the Rust Book, but tried to simplify it so you could make it through in about one and a half hours. I’d love feedback on it and I hope someone finds it useful.
A while ago, I built this super basic Sinatra app to post tickets to JIRA. Here’s the use case: you have non-technical people who are part of your company/team that need to be able to add bugs to JIRA. However, they aren’t putting the right information into the ticket. Here comes this super basic app. To get it running, you just need to update .env with your JIRA username, password, and project key. However, I would recommend changing it to use OAuth. Right now, the form is very simple and, if you decide to use this, I would highly recommend you update it to ask for whatever information you want. Just don’t forget to update the JSON in sinatra_jira.rb! This application is completely open source - feel free to copy any of it for any reason, whole or partial. Let’s dig in a bit and do a quick overview of how Sinatra works.
To start off, the Gemfile is minimal. The biggest thing is that I’m using dotenv, a super useful gem that helps manage environment variables using .env files. Other than that, rubocop, sinatra, and we are using thin for the server.
The main file (sinatra-jira.rb) contains the routes and the actions. It’s basically a combination of a controller and routes file all in one. The initial get just displays the form and all the work happens in post. Even that is fairly simple though… we just take the field contents and put them in the form that the JIRA API wants.
The form is pretty simple too and really ugly. I would definitely recommend adding some styling and don’t be like me… internal users deserve nice looking apps too! Since the problem I was facing was that I wasn’t getting the right information, I made sure to put examples in the form to increase the chance that I would get the information that I need.
This is a SUPER basic response. Don’t miss that we are passing key to the response. That is the issue key which, depending on how much your end users use JIRA, might be useful to include.
Hope this was somewhat useful in some way. I’d love to see feedback too!
I started my new job in mid-June and have had this in my drafts since my job search last year. I’ve now done two remote job searches and I don’t think I’m ever going back to a regular office job. So far, I’m really happy at Stitch Fix and I’m hoping I don’t have to find another job for quite some time (years??? 🤞🏽).
During remote interviews, have a list of questions and type up the answers as you hear them.
Often, companies will ask for you to do a 5-8 hour final interview via video. Feel free to push back and request that a video interview be broken up. I’ve noticed that it’s less likely for interviewers to think of someone on video needing a break and, since you are on video, it’s harder to ask for one.
If they want you to travel to do the final interview in-person, consider pushing back and asking for video interviews. Here’s why: you will be working with the company primarily over video. The interview process is what helps you evaluate how they work remotely. If they have to have you come in person for the interview, how can you be sure you won’t be stuck on dev island when you actually start?
Out of my questions I have listed, here are the two most important ones for remote jobs: What tools do you use for remote collaboration? How do they work together and ensure good communication and collaboration? These should be a priority because remote employees require good communication more than in-office employees. It’s easier to ignore them… so you want to make sure that’s not going to happen to you.
Mirror focuses on Ruby, JS, and mobile devs. I’ve used them a few times and it is only chance that I haven’t taken a job through them because they have consistently put me in front of companies that I hadn’t heard of that I would actually be interested in working for. I definitely would recommend them.
As part of my work with Arcadia, I've built a Rails application that added a cookie that contains a JWT (pronounced jot). Great! That was fairly simple. Then I had to go over to our Scala application and get it to accept the JWT as identification. Right now, we were keeping it pretty simple and we only care if it's valid. This post will cover what I think is the simplest way to do that, from start to finish. Or you can skip all that and just go look at the full gist.
We want to start off with the JWT parsing. And before we add the code to actually do that, let's add some tests! I decided to use the JWT Scala library and, in particular, jwt-core. It had, in my opinion, the most easy-to-understand documentation so I could indeed RTFM and get my work done. Since I didn't need to add encoding in the actual application (the tokens would be encoded in another application), I added a quick line to encode a token within the tests.
Now that I have my tests, let's add the actual code to decode the JWT! Thanks to JWT Scala, this is pretty simple! The real secret sauce is in this line: userTokenData = parse(decoded).extract[Token].data. That does a lot of heavy lifting! decoded is just a string and parse turns it into this Jvalue object thanks to json4s, but that object is a bit hard to work with. However, I can extract it out to my case class, Token, which is downright magical. If it doesn't include all the fields that I have in Token, it will produce an error. Perfect!
Next I need a reusable Authentication object. This wasn't too bad because I found out that HttpServletRequest has a method called getCookies which... returns the cookies. Excellent. I'm sure this looks weird as an Either, but in this case I really did want Some or None because I didn't care about returning the error to the actual user. I did want to log it though, hence the liberal use of println.
Last, but definitely not least, I need a servlet. Well... tests for the servlet, then the servlet 😛. This is where I actually ran into trouble because I wasn't sure how to pass cookies to the get request in a test. With some help from my boss, we found out that get takes a headers param and you can pass a cookie if it looks like this: headers = Map("Cookie" -> cookie_value). To be honest, it required a bit of trial and error and I'm still trying to figure out exactly what values are being passed.
And finally... my servlet! Short and sweet.
I went to RailsConf last week and it was an amazing experience. DHH's keynote reminded me why I love Rails. Eileen's keynote made me super pumped for Rails 6. And all the talks were a delightful reminder of why I love programming and why I love the Ruby community. Here are some deeper thoughts and notes, divided up by talk:
Note: I'll post links to talks that I reference as soon as they are up.
This talk really hit home for me since I was very recently battling with Play for 4 months. One of the things that I do really love about Rails is that I can focus on solving the problem I actually want to solve, not problems that have been solved before (like... authentication). And, while I do agree that junior developers and people just starting out should not have to know SQL, I do think that knowledge of SQL is still useful if you want to be a good Rails developer. Relying solely on ActiveRecord is a mistake.
This workshop managed to be both good and not quite what I wanted. I had hoped by the title that there would be a big emphasis on stubbing, but it was more of a footnote. It was a good crash course though and if you don't have much prior RSpec experience, check out Nicole's tutorial.
Jennifer Tu of Cohere gave an excellent workshop on interviewer skills that I have about 4 pages of notes from that I will try to sum up here. One of the first things she brought up was that a team should have specific goals in mind when interviewing:
For each attribute that the interviewers want the candidate have, they should ask questions that dig into how a candidate behaves. For example, if your team values kind feedback, instead of asking "Do you give kind feedback?" or "Are you nice when responding to pull requests?", ask "Have you ever given feedback to someone whose code was not good? What did you do? Why?". If you value independent learning, ask:
Make sure to wrap a question in context to ensure the candidate fully understands what you are asking. For example, one of the attendees wanted independent thinkers and people who would question decisions. They were currently asking this question:
You get a user request to add a blue button. How do you add a blue button?
However, in the context of an interview, someone who would normally question a decision like that might resonable think that the interviewer just wants to know if they know how to add a button to a page in HTML. What they should ask is:
We get a lot of feature requests and they aren't always valid. What would you do if you got a feature request to add a blue button?
Allow interviewees to show the skill if you can. Theoretical scenarios often just end up only showing red flags. Play acting is the better option. For example, if you want to know if someone gives kind feedback, give them some bad code and have them review it. If you want to know how they handle conflict, play act with the two interviewers coming up with conflicting ideas and ask them how they would resolve it.
It is the job of the interviewer to give the candidate the opportunity to show off. Interrupt (politely) if needed. You will be doing them a favor! Here are some possible polite interruptions:
You should also be sure to set an agenda and share rubrics with other interviewers ahead of time.
André Arko gave this talk on the best way to pair and, as someone who has paired incorrectly for a while, it was quite interesting. So the basis of pairing is two devs, one machine.
Discover & share this Ncis GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.
I can't not use this gif even though pairing is not this.
Anyway! You should be actively collaborating. The best way to think of pairing is to think of it as one little meeting. If done right, it should push you to be a better dev and away from bad habits. Above all, pairing needs trust. If you are condescending, that breaks the trust of your pair and makes you a lousy pair. One good way to pair is to have the driver write a test, codes until the test passes, writes a new test, then switch driver to the other person, who then repeats the process. Never say "let me do this quickly by myself." That is not pairing! Help the driver solve the problem and stay on the same page, so you both understand. There's a lot more to this talk, but I think you should watch it yourself 😃
Megan Tiu built out the apprenticeship program at CallRail and so we get to learn from her experience! To start an apprenticeship program, you need:
You can sell it by noting that apprenticeship programs:
Here's what you want to know about your plan:
For hiring your apprentices, you want an application (basic questions to get to the heart of what they are about), a code challenge, and a final interview. If possible, do end-to-end anonymization until they get to the final interview. You also want to ensure you have a rubric prior to starting this process. After you hire them, try giving lessons on foundation concepts, then give them small changes (bugs/internal code). Then rotate them around to different teams, including customer facing product. And don't forget to set early expectations!
Eileen Uchitelle totally pumped me up. She discussed the various ways she is looking to make Rails more scalable by default. One of the things that really stuck with me was when she mentioned how so many companies are doing these things individually... so why not make them part of the overall framework and share the knowledge!
Can you tell I am into interviewing? This was a talk by Pete Holiday, also from CallRail. Here are the problems with coding during interviews:
So what's the solution? The primary solution is to just talk to candidates.
That's it! But there's more. Here are three possible techniques for a code-free interview:
1. Dig into their experience. Let them direct you to what they feel is most important. Ask questions like:
2. Have them do a code review. If you choose this, make sure you are not using production code (they will have no context), are actively reducing complexity, and include realistic bugs without making it a bug hunt. One good option is to have a completely contrived situation with a simple application and a pull request to that simple app. Another is to fork an open source repository and create a contrived PR. The pull request should include no detail in the commit message, unsquashed commits, non-idiomatic code, overly complex, bad variable names, and actual bugs.
3. Try doing a collaborative system design. For this, you want to hypothetically build a tool, platform, or a project. You don't want any code or pseudocode and you should be working with the candidate. The general idea should be easy to understand and either related to the skills you're hiring for or well known. This can be forever-long, so it needs to be timeboxed. Let the candidate lead and build complexity if it's needed. For example:
Let's say we want to build Facebook. Get rid of the boilerplate (we already have users) and then ask "How do we implement status updates?". Once they get there, we can go deeper and ask about privacy controls, then granular privacy controls, and past that potential performance problems.
I loved this talk because I think code-free developer interviews should be the norm and have also been advocating for it at companies that I have been at.
H. Wade Minter gave this workshop and I don't have any notes on it because it was an improv class. But! One of the big things I took from it was our last activity. To remove bias from ideas, we did the following:
At that point, we had seen about 10 different ideas (plus our own) and the best idea could have a total score of 35 with the worst having a score of 0. Our top idea had a score of about 26, with a good number being around 22. We had a couple of bad ideas in the double digits (I'm looking at you, bacon table). This definitely seems like a good practice for any organization with a decent number of people.
I did some more, but I don't have any notes! I also sat and watched my friend Sam Phippen pair for an hour and a half, so if you want to learn yourself some RSpec, watch here!
I signed myself up to teach a Scala class through Girl Develop It Pittsburgh a few months ago and the class was supposed to be tomorrow. I say "supposed to" because we only had two people sign up, so we ended up canceling. However, I still made a presentation! And since I spent all that time on a presentation, I decided to make a set of screencasts to accompany that presentation. If you've ever been interested in trying out Scala, I hope this helps. If you need any help or want me to go through some other aspect of Scala, feel free to contact me.
Find the rest of the series here.