Field notes 003: When in doubt, write it down
Create a plan, create a schedule, send an update
I’m a software engineer now. I’ve noticed that I become a better engineer when I’m writing my learnings down. In this section of my newsletter I post daily learnings as I work to become a fantastic software engineer.
How do I become a good engineer?
At Fractal Tech today, Cam asked me what I’m up to these days. I told him that I’m trying to become a really good engineer. “How can I be a good engineer?” I asked. I told him I’m worried that I’ve become more lazy since bootcamp, less agentic - that I keep asking senior engineers for help, I keep stretching deadlines out, I’m struggling to feel more powerful and leveled up. It was helpful to hear from him that I’m not the only one that’s experienced this. Here’s what we talked about:
Communicate really well and give accurate deadlines on things.
Switch your hat. When struggling, ask yourself, “what advice would I give to a friend?” Your inner advisor and executor are very different. You might be flailing around when faced with a difficult bug - but often, you know what you actually need to do. There are a few evergreen pieces of advice - “Check the logs” or “write down your process” or “send a status update.” This seems widely applicable to life - when you’re flailing, it’s not that you don’t know what to do. You’re caught up in a story that’s keeping you emotionally stuck, and mentally “switching your hat” lets you step out of that identity.
I notice this when I mentally put on my “product manager” hat - I tend to write more skillful Slack messages, more complete briefs, and have more attention to detail in outcomes.
I think this “disconnect” between identities and hats has been a source of frustration for me - but there’s probably some spiritual wisdom here about masks, ego, and identity. Sometimes you just have to prompt yourself.
Visakan Veerasamy seems to create different alts for different parts of himself. I think it’s also worth reading into Jung, shadow work, and parts work.
Be prolific. A lot of getting good at programming is just getting the reps in. Starting a web server feels second-nature now even though debugging that was annoying the first 100 times I did it. There are many things that feel super awkward now that I just need to practice. This is why it’s important to just write and run a lot of software.
Take ownership. What happens when I can’t rely on that senior engineer? LARP this.
Create artifacts. Flowcharts can be nice - if this, then that. “have you checked the logs?”
The nice thing is that I’m rated on results, not process. I get to pick the process. The results are that I produce better and more reliable systems that produce positive business outcomes.
I also think that this thread about different kinds of rest rewired my brain and was exactly what I’ve been looking for - permission to use work to solve my emotional problems lmao. Specifically, one emotional problem - procrastination-guilt. Exactly as bayesian asian describes, if I am feeling terrible about work I think the solution really is for me to do more work.
I <3 field notes + scheduling
Man, I love these field notes. I notice that writing them has changed how I work during the day. I keep an eye out for learnings and jot them down in Notion. It’s almost like I’m working so that my field notes are better. I’ve shifted toward working to learn.
In my last field notes, I decided that I’m going to be more disciplined about scheduling and focus. This has felt awesome so far.
When flailing, make a schedule. And include every time block! Do it in half hour increments and fill every block. If there’s a conditional, or a potential branch, describe the branch and complete the schedule for both branches. A schedule is a structure that allows you to offload cognitive effort. Let yourself offload all of the effort. Cognitive effort spent upfront is cheaper than cognitive effort spent later.
Sara’s schedule she helped me make. She is a high school teacher after all 
Sometimes you need to make multiple schedules. Schedules are REALLY helpful. Maybe the title of this field notes (“field note?” we’ll do “field notes” because that’s cooler) will be The unreasonable effectiveness of making a schedule. I made two schedules today, and even though the one I made in the morning went completely off the rails, my second schedule was super valuable for me to get work done in the evening.
Schedule #2 Even though I got only two hours of work done, I felt really good at the end of those two hours and didn’t want to give up by the end. Another thing that contributed to this was that I felt really good about my progress - and that I had been able to create a detailed bulk upload guide and a utils repo. Creating artifacts really motivates me!
I felt really good and capable figuring out a Keycloak issue. That, along with sticking to a schedule, writing field notes, and workshopping my self description helped me connect to a feeling of ambition and ability that I have been sorely missing.
Write things down
Noticed something strange on Friday - I kept plugging along on things, but it felt not urgent? Like I was just taking my time, getting distracted by other random tasks, not even necessarily Twitter. Need to work faster I think, even though I had uninterrupted time to work. I think that I overcame this Monday evening because I was writing down and vetting everything I was doing as part of creating the bulk upload guide. When in doubt, create an artifact, create a plan, write down my process, send a status update - it really motivates and helps to unblock.
Do tasks early. If there’s a critical SLA to meet, work on it early to advance it forward. We discovered a bug that unexpectedly delayed the progress of the bulk upload, even though I felt I could theoretically “figure out” everything that needed to go right.
Send status updates frequently. “Hey here’s where we are, here’s what we’re blocked on. Here’s what our next steps are.”
We hit a sign-in bug and I felt stuck and didn’t know how to help. Still don’t really. I got intimidated by some messy logs that I had seen previously. Same refrain: write down my process.
Technical learnings and observations
docker psallows for listing all of the current running docker containersps aux | grep postgresis pretty cool. Grep is pretty cool in general. What does the|operator do? looks like it allows me to send a command or process the output of the preceding command.ooh interesting. good guide: https://www.codecademy.com/learn/learn-the-command-line/modules/learn-the-command-line-redirection/cheatsheet
oh the distinction is the double arrow
>>will append, but>(clobber) will overwritethere’s some concept of there being a
postgresuser.
Open-ended claude questions really helped. See the output of the process of “hey how do i query the Keycloak admin api” and just pasting the docs. It gave me the steps i needed.
I felt a little bit “barely hanging-on-y by the seat of my pants” when having Claude write some utilities needed for JSON manipulation. Not sure if this makes me a good engineer (I’m doing what it takes to ship) or bad engineer (sloppy and too fast). Ultimately a senior engineer caught an error where I was treating a field as a string, when it needed to be an integer. I should, more than anything, pay attention to the forms of data and what they need to be at the start and finish of transformations, even if I use AI to write the processes for those transformations.
What should I rate myself on as an engineer? Things I can do myself? My effectiveness overall? Business outcomes? I’m interested in what I can drive towards every day.
(If you’re not interested in getting these updates, but you’re interested in staying subscribed to the rest of my Substack where I write about more than just tech, you can unsubscribe from the specific section “[yelling computer].”)