Ask HN: I just got my first job and I need to learn faster and better
A little background: Self-taught web developer, hired to work with both frontend and backend code. This is my first software development job.
My problem is, I'm slow to pick the technologies needed to start working on JIRA tickets. I'm working together with another junior developer (also self-taught, started same day with me) but I'm just stuck eating his dust. I decided to put egos aside and ask him for help and the only thing I got was generic advice, which I already do (read the docs, understand what you read, try building their tutorials/getting started section, read more code, trial and error).
Either I'm inherently slow and it's time to accept the natural limits of my brain or there's a better method that would work for me and I'm missing it.
35 comments
[ 4.3 ms ] story [ 31.5 ms ] threadBut just for the sake of being specific, it's Python with FastAPI. But it's not just the FastAPI docs (which help) it's also the architecture. The project is in a scale I never worked with before and I'm so bad I don't even know how to debug it. It also uses a microservices architecture, so it's not just the FastAPI but also Python scripts running inside multiple Docker containers.
I told them I've only worked with Python for small projects and coding challenges, the other guy also claims the same but still he does a much better job covering ground compared to me.
Just today I've spent 4 hours going through the FastAPI docs, poring over every single line of code to understand what is happening. Googling every unknown line, making anki cards, etc.
As others mentioned, I'm also entirely self-taught and it comes from personal projects.
I'm sure you've seen it, but if I was going to learn it I'd start here: https://fastapi.tiangolo.com/tutorial/
Then I'd build something for myself, something that actually works, that I actually deploy. Because so much learning comes from doing.
Pick a project you want to launch, or build an open source tool. After 3-5 you might feel quite comfortable. But it probably will require a lot of extra time outside of work. I learned Rails outside of work and I spent most weekends and a few nights a week for a month before I felt comfortable enough to work on production code.
I also like video tutorials, so maybe try Googling and see if there's a YouTube video series that clicks for you. Sometimes the medium of spoken word just works better for me than reading.
The other thing to remember is that no two projects are the same. The FastAPI project you might be working on might be in a very different style than the ones in the tutorials. Just so you don't overwhelm the other dev, maybe write down a few questions in the morning and ask them all at lunch time. Otherwise, if you're asking every hour it might get overwhelming.
Good luck!
Also, I'm feeling like I may get too obsessed with syntax. I author multiple anki cards throughout the day. Some are things like "difference between concurrency and parallelism", while others are like "3 ways to add a new item in a list", "docker command to run a container detached".
I respect they might be busy but two new starters who are at an equivalent experience level should be getting support. Reach out to them, find the one that has the best personal skills and lean on them. If they are really busy make sure you're making the most of their time.
* Take notes * Ask good questions * When they provide you information, ask for them to provide you a link to supporting documentation so you don't need to ask the same question twice
Even with all of this, you might not get the support you need. If that happens, it's not a reflection on you but a reflection of the organisation or it's current (or permanent) situation.
To echo the other people who replied, this isn't a You problem. It's normal to feel somewhat lost when thrown into a new codebase. I felt that way when I started at my current job, and three years later I don't feel lost but there are definitely parts that I don't fully understand.
Talk to your senior engineers, and/or your on-boarding buddy, and tell them that you're feeling lost and are trying to understand how to debug the problems better, or how to understand what's going on. It will help if you have a specific question (e.g. "how does this code even get executed?", or "where does the data come from that this is using?"). However, a BIG part of being a senior member of the team is being able to help newer people navigate the new codebase. ("New" as in new to the team, new to this code base -- it applies even to engineers with more experience than you.)
Consider asking if you can shadow them and watch how THEY debug similar problems, or find where the code + tests is for things. If it's in multiple projects and repos, ask how they know which one to use. Ask them to show you how to get a usable debugger (`ipdb` or `pdb`) prompt in the code you're trying to work on, and how to find (and execute) the tests that exercise its behavior. If it's non-trivial for you to do it, they almost certainly have their preferred way to do it. Also, talk to more than one engineer -- they may have different solutions.
You probably lack a big picture, try to create architecture diagram this will help you orient. You don’t need details of FastAPI. You have docker but how is communication between services done? How its deployed? How you debug? Do you have distributed tracing? What DBs? Learn the data schema and also problem domain.
But then I might end up not recalling many things later. Can I even claim that I'm "learning" like that? What if I end up being someone using older projects as a reference? Is that even acceptable?
When I started, I was similar. I read K&R C cover to cover, then sat to write a toy program and didn't even know how to start. Lesson learned.
Now when learning a new language, I scan the docs, then sit down to write something. Line by line, word by word if I need help(and I do), I'll find a reference, write it, move to next. And you'll learn that way, from repetition.
In short - less thinking, more doing.
This is interesting, because K&R's strongest point is its exercises. I'd almost call it not worth reading if you aren't going to do them, but if you did the exercises (which get deep quickly) and came out unable to write a program that's a bit baffling.
You need to start practicing outside of work. I'm also self taught. But you need to never stop self teaching. I learn 90% of what I know outside of work, and I've been a software engineer for a good while
The next best thing you can do is make a work log, save every single stackoverflow or documentation link you visited, take notes and document everything you learn, do or want to do. Whenever you do something or are unsure, make notes to ask the senior devs later on. It wouldn't hurt to ask the other junior dev if he wanted to pair on a ticket as well to observe how they work.
The other day I was brought on to a project that uses gRPC, I've only ever briefly looked at protobufs and with one weekend, I learnt how the proto files worked, the tooling around getting setup, made A LOT of silly errors, got stuck, unstuck and stuck again but eventually made the simplest application that stored locations to a sqlite database. The following week I made my first PR to the project because I could identify what was what, the project structure was much different and complex compared to my small app but the concepts and how everything worked made it a lot easier than just diving in headfirst which when in retrospect would have been next to impossible.
Is this also true for other professions, if not, are there decent professions where I can simply put in an enthusiastic 40 hours but just 40 hours?
The side-effect of that is, you "only" have whatever stack they're using as your marketable skillset.
Let's just say you're an auto mechanic, odds are you do work on your own cars as well.
I do wish more programming interviews were about side projects instead of Leetcode. I still struggle with Leetcode interviews, but I'm not willing to sacrifice my hobbies.
It's fun to make mobile apps, it's not fun ( for me) to solve Leetcode questions.
It gave me insights that my peer developers didn't have. I became aware of the entire life cycle associated with an application and learned enough of the various moving parts to understand the full picture of what was going with the application we work with at daytime-job. To have this understanding gives you a huge leap over your peer developers that only understand what is going on inside of the code silo.
My AD environment might not be of a quality that could be deployed in production in a real enterprise, but it enabled me to participate in discussions with infrastructure people and to better understand what could be root cause of the errors I had to troubleshoot during a normal days of work.
Having my own mini enterprise setup also allowed me to check out and learn about future features and suddenly you find yourself capable participating in talks with architects.
In addition as subscription to Plural sight online training also helps in learning quick and get a overview of various tech.
I'd try focusing 100% on getting the task at hand done while at work, but noting areas that are difficult for you and then doing some experimentation and side study on those areas after you get home. In order to make it at your first software job in a new industry, you'll possibly have to put 2 hours a night into self-directed learning.
Just focus on breaking down problems into manageable chunks. I can't emphasize this enough. As for FastAPI specifically I'd check out the sample postgresql project tiangalo made, it's incredibly well put together.
[1] https://github.com/tiangolo/full-stack-fastapi-postgresql
I often thought that my inadequacy at a previous company had to do with lack of technical knowledge, and even though that was true I was not familiar at all with the project I was working with.
Use the debugger a lot, step through code until you have an idea of what is doing what and why is doing that. This knowledge would help you have better questions, i.e. instead of something like “how does the widget X works” have questions like “why when X happens are we making Y API call?”
At the end of the day, remember that you are paid for making money for your company, not for above-average technical skills! So, focus on the task at hand, throw console.log and debugger everywhere and understand your company’s app and how they are using whatever technology they are using.
I’m also self taught and I’ve been there, you got this!
After working with him for a year, I still didn't know and I still don't know. I offer this to you because, you will not always be better than the people around you.
That being said, its worth investigating the python debugger if you haven't already. import pdb; pdb.set_trace() - this will drop you into a debugger at the spot in execution that will allow you to examine variables and iterate through for loops. This has previously helped with my understanding of Python.
But, my big message to you is to not get taught up on comparing yourself to other devs. You will excel on some things and not be great on others. You will be slower than some and faster than some. Try first of all not to stress about your performance, but keep a learning mindset. From my perspective you seem to have your heart in the right place!!!
> Programming isn't especially difficult in my opinion.
Spoken like someone who is a programmer! haha
When I was learning simple syntax I used to be afraid, almost allergic, to the idea that the code I'm executing will produce errors. I realized too late that the faster I get to the point of erroring and interpreting the errors thrown the better my progress. To put that in the kitchen perspective, it's the point where you're sampling the food that you're cooking to see if it needs salt, you forgot the onions, or it's boiling too fast.
We have all been there before. Don’t sweat it too much but also don’t ignore it (you don’t seem like you are so that’s good).
Idk what you’ll be doing more of. Identify where you’ll do most of your work on focus on that. DO NOT try to learn everything at once. Maybe that means building a react app with no backend and using 3rd party services. Maybe it’s making a pure api backend and using paw/insomnia/postman to query it.
1. Go to seniors before you go to Jrs for advice. There’s a reason someone is labeled “senior”.
2. Read read and read. Go find a book on fastapi if it exists.
3. Document anything you find weird. Your coworkers will love you for it. Documenting is like teaching and you can’t do it without understanding that piece of code. Furthermore, when you make a PR with those new docs, your coworkers get a chance to say “hey you don’t fully understand this”.
4. What areas are you weak on in fundamental programming? I find most people that struggle with a framework really lack understanding in the fundamentals. If you do not, go read a book.
Python: https://www.amazon.com/dp/1449355730/ref=nodl_?tag=hackr-20&...
Js: (No book just read mdn) https://developer.mozilla.org/en-US/
None of these are attacks. Be honest with what you don’t know and go learn it!5. Create a project with the exact technology. Deploy it to the same services. Yes deploying is Ops but understanding the lifecycle of your code is important. Yes you will rip your hair out deploying on aws instead of heroku. Yes it will suck. But yes, you will be a better programmer.
This is going to be the most important one: 6. Stop comparing yourself to others. Time of programming means nothing. Unless you both read the exact same books and did the exact same projects and solved the same leet code problems, you’re comparing apples to oranges. For all you know, they could have a mentor. Maybe you were reading the worst guides ever and they read the best. Pondering how this happened won’t do you any good. Just keep moving forward!
Programming is not a job you get to walk away from after your 8hrs. You can but others will leave you in the dust.
You can do this! Do your best not to stress the day to day. Focus on growth. I promise you, if you focus on learning, 90 days from now you’ll question why you were even stressed out. You just have to be honest about what you don’t know and learn it.
1. Focus on specific task first. The most simple you can have.
2. Find someone more experienced in this area to mentor you to achieve the task.
3. Repeat with more complicated task.
Also follow people that lead given tech and competing/emerging solutions
> I decided to put egos aside and ask him for help and the only thing I got was generic advice, which I already do (read the docs, understand what you read, try building their tutorials/getting started section, read more code, trial and error).
Useless advice from a useless junior. Ask someone more senior to help. You'll have better results.