Getting My Groove Back, and Surviving Dysfunctional Startups

Especially in the Tech industry, feeling safe enough to vent and emote authentically is vital to career health and progress.

Hello there! 👋🏾 First off, WELCOME to my newest subscribers! 🎉

Y'all are spoiling me with your support; I received several encouraging responses to my last newsletter. I’m grateful! 🧡

Ok! Jump in below, and enjoy! 😉

PS My meeting schedule is open again for anyone needing tech career counsel.


How Arit Got Her Groove Back 💃🏽

I just completed my first project after quitting a huge one (click here if you missed that!). This recent project was more than a mental breather; it was my opportunity to return to feeling like a capable coder who can implement a feature or task from start-to-finish, at a high quality standard. With this new project, I aimed to apply all the competencies I had gained from the last project, and I was also looking forward to learning something new. ✨

In a nutshell, this project called for the refactor of Forem‘s Sidebar. Currently, the sidebar displays up to 5 navigation links, with a More... button underneath; if there are more than 5 navigation links, clicking this More... button reveals the remaining links. The refactor called for two distinct sections within the sidebar, and all navigation links divvied up between these 2 sections. The More... button was to be deprecated.

Depiction of New Project's Goal

Depiction of New Project's Goal

My first step was to implement those project aspects that wouldn’t affect the user-experience on the front-end:

  • add a section column to the navigation_links table

  • set a default section value

  • backfill the section column for existing links

  • ensure that changes to a link’s section persisted to the database

  • write/update relevant tests

My next step was to implement the user-facing aspects:

  • update the sidebar to display the 2 sections with their links

  • update the admin portal (where links are managed) to display the 2 sections as well

  • write/update relevant tests

During review of my second pull request, my teammate Suzanne left several useful suggestions for enhancing my code’s accessibility. I welcomed her contributions because I do want to improve my accessibility skills.

With this project done, and with my groove back and humming along nicely, I’m ready to tackle another large project: refactoring all Save Confirmation functionality in our app. This should be good! 😅


Functioning Well At A Dysfunctional Startup

Some time ago, an early-career developer (let’s call them Carey) scheduled a 1:1 chat with me to discuss difficulties they were having at their first (remote) tech job. I looked forward to our talk because I wanted to do all I could to encourage them, and give them practical tools to navigate their situation.

Carey shared that they worked at an early-stage startup, completely bootstrapped with no short-term plans for venture fund-raising. When they got the job, Carey could hardly contain their excitement! Before their start date, Carey prepared their household, created a schedule and set up their home office, all the while oscillating between anticipation, exhilaration and nervousness.

Fast-forward to the present, and Carey almost regrets taking the job. The first issue they experienced was the total lack of project management among the developers. Carey was almost in tears as they recounted to me how their code had been overwritten several times by other engineers, only to be asked by the team lead to redo the work. What’s worse, the developers over-writing Carey’s code never acknowledged their actions or expressed any remorse over Carey having to re-code their work.

Another issue Carey faces is a company culture that revolves entirely around those employees who were all friends before the startup was established. Workers outside of this friendship-circle (Carey included) often feel marginalized or ignored, and there are virtually no regularly-held rapport-building activities. Compounding the situation is the fact that many of the company’s decisions appear to benefit this friendship-circle the most, before other team members are considered. For Carey, this atmosphere extends to their relationship with their manager, who apparently lacks the power to sponsor or advocate for Carey to any meaningful degree, and often replies to Carey’s requests with: I’ll check with <insert founder’s name here> and get back to you.

I was happy to be Carey’s sounding board because I believe that, especially in the tech industry, feeling safe enough to vent and emote authentically is vital to career health and progress. I asked Carey what their immediate career goals were; they replied that they’d like to get a solid 9-12 months of work experience before hunting for a new job. So I shared the following counsel for the rest of their time at the company:

  • Document Work and Communication: as long as the issue of over-written work continued (without explanation or accountability), I advised Carey to keep records of their work, as proof of their output. I also advised them to follow all verbal communication up with an email summarizing the convo’s key points, as a way of documenting decisions and agreements.

  • Maintain Boundaries: I encouraged Carey not to feel obligated to work overtime or outside of work hours, in order to protect the rest of their life and mental health. I advised them to block off hours in their work calendar to show when they were unavailable.

  • Keep Network Warm: even though they were not actively job-hunting, I advised Carey to start warming up their professional contacts; an example of such is to email/text/tweet your contact about whether their company is hiring.

  • Protect Sense of Professional Worth: in a work environment like Carey’s, it is so easy to start feeling incompetent, especially as a first-time developer. I advised Carey to stay involved with other coding communities (like healthy opensource projects) where they could feel better supported, and contribute meaningfully.

You may wonder why I did not advise Carey to “fight” the issues they were experiencing. Simply put: I don’t think it is their problem. Carey, as a first-time developer, is at the point of their career where they need to focus on their technical growth and opportunities that provide for this. Period. In my humble opinion, becoming distracted with the clearly chronic problems that this company manifests would be a mistake for Carey.

Carey’s experience is a cautionary tale about how transitioning to a coding career is not always pleasant. What do you think about their experience and my counsel on how to deal? I would love to hear your thoughts - please respond to this newsletter, and I will post some of your responses (anonymously, of course!) in the next issue.