Taro Experts

How credible is it that some algorithm will be able to write code at e4 or even e5 level? That will probably happen. How credible is it that some algorithm will replace e4 engineer in the foreseeable future? Very very unlikely.

Current algorithms are unable to properly reason, they are unable to solve novel problems, they are unable to prioritize. There is nothing yet in the works that overcomes those... not sure deep learning as it is currently is able to do so.

Engineering is not about being a coding monkey but about solving abstract problems where sometimes the real solution is "do nothing".

Silicon Valley leaders have an agenda. What they say about "AI" needs to be looked at through that filter.

Like Sai and Charlie mentioned, it takes a certain amount of effort to make AI actually work for you when coding. AI is good for:

• extremely common code patterns
• shuffling simple stuff around (variable name changes, small function refactors)

Larger design decisions that span multiple functions/scripts don't work very well. Similar to how Alex mentions breaking down units of work, breaking down work even more with atomic tasks helps you get a way better ROI on AI tools. I use this process:

• break down tasks to the function level
• insert some comments to annotate what I want Cursor to do
• use the chat interface and feed in context for each mini-task
• audit your code by looking at it/testing it

Rinse and repeat.

The way I like to think about it is that AI is 100% useful on 20% of your work as a SWE (doing mundane stuff like regex, etc). Cursor can't help you distill requirements or make a great design. Cursor also won't help you manage expectations with your boss.

There were periods of time in my Staff engineer role when my work day got extremely fragmented. Here's how I used 10-15 min blocks:

1. Read some code that was recently merged.
2. Familiarize myself with new Datadog dashboards to learn more about my own systems or adjacent ones.
3. Read TDDs/ADRs from adjacent teams that asked for my inputs or to learn about other systems at the company.
4. Catch up on eng-excellence type channels and read an article or two shared there.
5. Catch up on shipped type channels and take stock of the newly shipped features.
6. Respond to backlogged DM's with coworkers discussing topics of interests outside of the immediate workstreams.

You will notice that, in none of these tasks, I was actively accomplishing a parallel/competing task. OTOH, I was using this time to squash other myriad misc tasks that would otherwise keep me from focusing on my primary tasks.

These tasks are "small" in nature, so they keep you from getting sucked too deep and losing track of your original task. Left unattended, these tasks pile up and create backlogged requests from others/anxiety/FOMO, all of which are detrimental to mental health—and erode the feeling of being "in control" of your surroundings.

As an entry-level SDE, your list of misc tasks will look very different, but the above list should give you an idea of what it should look like for you.

A few other finer points in what you wrote:

1. You mentioned "silly mistakes." Can they be avoided using a linter, etc?
2. Also, are you in the habit of doing a static walkthrough of the final version of your code before putting up your PRs? Doing this does take an extra 10-15 mins (or more depending on the size of the changeset), but it has almost always helped me catch typos, unfit variable names, incomplete comments, etc. that reviewers would otherwise comment on (and I'd feel bad about). Sometimes, static code walkthrough has helped me catch minor bugs that I'd missed in both logic and unit tests! I can't emphasize the ROI on static code walkthrough enough.
3. When multi-tasking, switching between multiple codebases is almost never a good idea as there's just too much context to carry in your head. Mistakes are inevitable. It also breaks your flow very badly if the different codebases are in different languages!

Hope this helps.

There can be many ways people would prefer, but I doubt any of them would be jumping and changing context every 10/15 mins.

Personally, depending on the type of the tasks, urgency, and size, I would give say a fixed percentage per day, then split the days accordingly. If the build/deployment times are taking an hour or more, it makes sense then to switch, otherwise I would invest this small time into pushing my changes to an unpublished CR, getting the hosts ready for testing, etc...

Context switching is expensive, do it wisely, as en entry level SDE, you need to deliver work, too much of that will prevent you from even delivering the smallest tasks, and getting accounted for that.

If you really need space and time and have the money to pay for rent/mortgage for a few months, you can try applying for FMLA & using that leave to study for your next job.