In this episode, Dave and Jamison answer these questions: A listener Steve asks, How long is too long to wait to be paid? I’ve worked for 4 early stage startups in my career. Two were successful. One failed. My current one is “limping along” but showing signs of taking off. At the startup that failed, we stopped getting paid and some of us stuck around for 2-3 months until the CEO closed the business. I ended up unpaid for nearly 3 months of work. At my current startup, we are 3 months behind, and it has been this way for 6 months. The CEO is transparent about fund raising and clients slow in paying invoices. My question is still how long before I follow your age old advice? Listener Jess asks, ‌ How do I get past survivors guilt when my company does mass layoffs, but I am not one of the casualties? I’ve been at the company less than a year, and this is the second time they’ve fired THOUSANDS of people, including from my team; folks I work with at least weekly, and folks who have been at the company significantly longer than I have. I feel guilty that I, “The new guy”, am still employed, but the folks who’ve been there for years aren’t. How can I get past this and keep working to ensure I’m not caught up in the next round of layoffs? My manager says I’m doing good work, and the layoffs included complex inputs, but it that only helps a little bit.

In this episode, Dave and Jamison answer these questions: I recently started listening to your podcast from the very start of the show! One of the largest differences I noticed (aside from the audio quality, lol), is how often you used filler words like “um”. How on earth did you manage to stop using them? In work presentations and demos, I often end up using the filler words, and listening to the recordings later is painful. The rehearsed parts of the presentation go smoothly, but as soon as I go out of the “script”, I start depending on filler words. How do I get better at this? How exactly should spikes go? I’ve done some deep dives to understand the scope and steps of an upcoming effort, all with detailed write-ups, only to later realize during the implementation that I got some things wrong or missed out some important details. Isn’t that the point of a spike, to root out any unknowns or surprises? Short of just doing the actual implementation, which I’m pretty sure is also missing the point of a spike, What am I doing wrong and how can I properly present post-spike findings to my team?

In this episode, Dave and Jamison answer these questions: My architect is too busy with his kids! His kids have had a lot of school and medical issues over the last few months and he’s ended up flexing a lot to take care of them. This causes meetings to get rescheduled or scheduled far out in the future, which is contributing to timeline delays on some large projects that need more attention. I don’t want to be rude and insist that he put the company above his family, but he needs to be driving organizational alignment, not his kids! I’m stressed out by not knowing when he’ll be available and having to do extra work or take important meetings without having him as backup! ‌ Can you help me understand what happened here? I was put on a ‘performance improvement plan,’ and it became pretty clear to me from the negative feedback at my first review that I simply didn’t have the skill to perform at the level that was being asked for. Instead of immediately looking for a new position, I decided to take some personal time off to work on myself and my mental health, and to use the remainder of the performance improvement plan time to prepare myself emotionally and financially for that. I didn’t blow off work, but I also wasn’t invested in the performance improvement plan either. A few days before my final review, I quit instead of being terminated. Management seemed really confused and angry when I quit. Why would they be so upset if they were about to terminate me anyway? One in particular started backtracking and pretending like I wasn’t going to be terminated.

In this episode, Dave and Jamison answer these questions: I work at a startup that makes embedded devices and the software that runs on them. Everyone on the tech team does both. We recently hired someone to lead the tech team to give the CTO more time for other duties. My new boss is incredibly experienced with hardware design and embedded systems and has been in the industry for a long time (40+ years). However, they are not familiar with modern software practices like version control. They will frequently ask us to do things like delete all copies of a broken version of software. When we try to explain how git works they will ask us to make a new repo with the now working version of the software even if the fix was a 1 line change. How can I politely explain that they just don’t understand how this works and correct them without being rude? What’s a “normal” rate of performance firings on a team/engineering department? I recently got a new job at a growing startup, and it’s fairly uncomfortable seeing the ghosts, on messaging apps and docs, of like 6 people in the ~25-person department who’ve been fired in the last half year. With that said, the department is continuing to hire, so I don’t think this necessarily means I should be worried. But does that sound like an unusual amount of performance-based firings?

In this episode, Dave and Jamison answer these questions: I work for a startup with a distributed team. Recently one of our clients experienced a production outage. As a small startup, we do not have an on-call rotation, and teams usually resolve issues during business hours. However, during this particular incident, most of my colleagues were on annual leave due to an Easter break, leaving only 10 out of 70 engineers available to assist. Although none of these 10 engineers were part of the team responsible for the outage, I was familiar with their codebase and knew how to fix the problem. Additionally, I had admin access to our source control system which allowed me to merge the changes required to resolve the issue. This was the first time I had done this, but my changes were successful and the problem was resolved. Now that the break is over, the team responsible for the codebase is blaming me for breaking the process that requires each pull request to have at least one approval and for making changes to “their” codebase without their approval. They want to revoke admin access from everyone as a result. However, I disagree with their assessment. While it is true that I made changes to a codebase that was not directly under my responsibility, I was the only engineer available who could resolve the issue at the time. I believe that helping our clients should be the priority, even if it means bending the rules occasionally. Did I make a mistake by making changes to a codebase that was owned by another team without their approval? Should I have refrained from getting involved in the issue and adopted a “not my problem” attitude since the responsible team was not available? Thanks and I hope I’m not getting fired for helping a paying client! J Dot Dev asks, ‌ What’s the worst thing you’ve had to do as a software engineer with direction from your employer? Years ago at a webdev shop we had a client who didn’t want to pay for e-commerce set up. My boss’ solution was to implement a form that included name, address, and credit card information fields that we would read on form submission and then email all of that information to our client in plain text. “Is that really ok?” I asked my boss. “Why wouldn’t it be?” “Isn’t that insecure?” “Only if they have her password. Just make it work so we can be done with them.” To top it off, they also had me email the information to myself just in case the email didn’t go through to the client or in case they accidentally deleted it, so I’d have all of this information just hitting my inbox.