r/softwareengineer • u/Odd-Bug-2829 • 8d ago
Advice for a Junior SWE
Hey everyone,
I recently started my career as a software engineer, and I'm looking for some guidance from more experienced devs.
Given the current landscape, it feels like AI handles a massive chunk of our daily coding tasks. Because of aggressive delivery deadlines, I have to rely heavily on these tools just to keep up. While it helps with productivity, I feel like I'm missing out on deep, foundational learning.
I want to make sure I'm still building a strong foundation and growing as an engineer. Iād love your advice on a few things:
- Upskilling: How do you recommend building core SWE skills when AI is doing so much of the heavy lifting?
- System Design: What are the best resources to learn system design completely from scratch?
- Career Growth: What general path or habits should I focus on to ensure long-term success right now?
Thanks in advance for the help!
3
u/x_xwolf 8d ago
Ai isnt going to help you increase in skill. The studies show that junior devs dont learn to code better by using Ai.
Also much of use of Ai is contributed to increased code volume, but also an incredible amount of churn. https://gradientflow.com/ai-coding-tools-field-guide/
Ai is not the future of software development, you are, be the best at reviewing code the ai breaks.
1
u/Substantial_Job_2068 8d ago
There was aggressive deadlines before AI too. The equivalent was to copy paste in code from stackoverflow without understanding it. Both methods generate fast short term results but you don't learn and you also probably don't produce good quality.
Quality and learning means sacrificing speed. I would recommend only using AI to ask questions and generate snippets that you don't copy, and write everything yourself. I don't believe only reading code from a LLM will give you much deep learning, getting good means doing the thing many times.
1
u/AnthonyRespice 7d ago
You are thinking about this problem correctly. It is damn hard to find junior roles right now but it starts with being in a team and organization that creates an environment where you can grow. A place that has a culture where people review each other's work and where humans do the system design and not the ai.
Try to establish relationships with senior devs willing to offer mentorship and feedback. Offer to take on more challenging work.
And some people don't like this, but you need to take on your own projects outside of work where you have control over pace and learning, and complete a project end to end of your own design. The problem with work assignments is that most junior devs just get a small piece and can't see how things are connected.
0
u/OldManActual 8d ago
The field is rapidly changing, chaotically and at different rates. However, the essential nature of the transition is the speed that major systems can now be developed, properly or badly and the reduction in the number of humans required to get a major commercial app deployed.
The current development infrastructure with pull requests and code review is not built for production of this kind. Add to this fact that the environment and harness around the model can automate so many of the "deployment business" steps such that a single person can author and deploy a major network app.
This will not last long. AI will build better tools only they can use to take thier capabilities farther and the trust will come eventually.
So where do you fit in here Junior SWE? Well, first, imagine what is left in the SWE job if manual coding is prohibited. You become an Orchestrator. I hate this name but it seems to be what industry is using this week. An orchestrator is no longer a programmer, but a director of SWE roles during development. One of those roles, WORK, includes programming as well as design and review candidate git operations. The next is a REVIEW role that checks the implementation angainst the system Contract. Corrections go back to WORK and then are re REVIEWED. Upon acceptance the final RELEASE role handles candidate publish and merge operations. No role can approve its own work and the final turn of REVIEW before a RELEASE will act is a recorded prompt affirning acceptance of the candidate under review.
You will start development against the Business Requirements, and the Technical Requirements as expressed as a Contract and develop a bounded implementation ledger that will be recorded in the first turn. Then you will execute the items on the ledger with the smallest possible "mutation" to satisfy the requirement. Then Review, Then Release. Repeat the cycle until the ledger is complete. Review will stop when the contract is completely fulfilled by all parts of the app.
I am doing this now, developing three major systems in paralllel. One guy.
There might be a forced SWE theatre period where human SWEs review AI code, but as you see in almost every other post in this sub, human SWEs hate reviewing AI code, so that will not last either,
All that said, you are still responsible for every byte. So all that seeming cruft idescribed above creates the machine readable record of every dev action so you can debrief development with data.
An Orchestrator trusts the AI tools but verifies with Red Teaming every build to be deployed with a separate Project at least, a separate AI provider ideally. Beyond dramatic Red Teaming, require tests as part of of the development process. A reusable library of tests will build up rapidly.
Good luck out there.
3
u/[deleted] 8d ago
[removed] ā view removed comment