Ask HN: How to know what I don't know, early in my career
22 comments
Avoid getting distracted by every new thing you read about, from frameworks to architectures. Focus first on the fundamentals of software development, which often aren't taught:
1. Break things down into small "complete" steps. Nope, smaller than that. Nope, you can still break that down. Test-Driven Development can help here, not by making sure you've got good test coverage, but by encouraging you to break down the solution into small, testable pieces.
2. When learning something new, don't copy-and-paste. Retype it if you have to, but at least understand _why_ that code will work, and maybe a bit about _how_ it will work. As you get more experienced, you can copy-and-paste, though you'll find you'll do that less anyway.
3. Related to 2 and the post about technical communication: learn how to concisely ask questions. The number of juniors (and seniors) asking questions, but failing to show the precise problem (or at least what they think the problem is), with enough code (but not everything!) to evaluate is...frustrating for those of us who want to help. Tell us what you tried, tell us what the errors are (precisely, i.e., here you want to copy-and-paste!), but do so with as few words as possible. This is _definitely_ a skill, so you'll get better as you do it more, so pay attention to the questions you get in response to your question. Reflect on whether that could've been included in your original question.
1. Break things down into small "complete" steps. Nope, smaller than that. Nope, you can still break that down. Test-Driven Development can help here, not by making sure you've got good test coverage, but by encouraging you to break down the solution into small, testable pieces.
2. When learning something new, don't copy-and-paste. Retype it if you have to, but at least understand _why_ that code will work, and maybe a bit about _how_ it will work. As you get more experienced, you can copy-and-paste, though you'll find you'll do that less anyway.
3. Related to 2 and the post about technical communication: learn how to concisely ask questions. The number of juniors (and seniors) asking questions, but failing to show the precise problem (or at least what they think the problem is), with enough code (but not everything!) to evaluate is...frustrating for those of us who want to help. Tell us what you tried, tell us what the errors are (precisely, i.e., here you want to copy-and-paste!), but do so with as few words as possible. This is _definitely_ a skill, so you'll get better as you do it more, so pay attention to the questions you get in response to your question. Reflect on whether that could've been included in your original question.
>Somethings are easy to argue for. I.e. look at used techstacks and how they work together (React, FastAPI, sqlalchemy).
Are they? If you recursively try to answer the question "why", I'm certain you'll end up at some level of "because uhm, because uhm... Because I saw someone else do it that way and haven't given it much thought".
Conversations with beginners who know nothing to assume anything is a humbling experience. Some of questions they ask seem to cut right at your area of incompetence.
Are they? If you recursively try to answer the question "why", I'm certain you'll end up at some level of "because uhm, because uhm... Because I saw someone else do it that way and haven't given it much thought".
Conversations with beginners who know nothing to assume anything is a humbling experience. Some of questions they ask seem to cut right at your area of incompetence.
>I.e. look at used techstacks and how they work together (React, FastAPI, sqlalchemy).
I see a vast number of posts on HN about React or some other web framework.
There’s more to software engineering than learning the latest flavor of how to render webpages.
Many projects don’t require the complexity of these frameworks and all the added middleware and layers upon layers of tooling.
These are bored people, who solve the same problems again and again, and invent new forms of complexity as if they’re undertaking the Gemini missions or Apollo missions.
It’s less about frameworks or specific tool chains. The biggest piece of advice I can offer you is to get out of your comfort zone, and learn to manage complexity and ambiguity.
This is what I didn’t know earlier in my career.
It’s not so much about quickly learning whatever new framework to once again solve the same problem people have been solving for decades. It is, however, about simplifying complexity, and thinking about how you or your team will support something in the future, will your solution be extensible as and when your product evolves, etc.
Work on projects where you solve problems that are hard to you. Work with more senior people whenever you can. Learn from them. Get comfortable with being out of your comfort zone.
But don’t burn yourself out. Drink water. Exercise. Don’t let your job become your identity.
Also, work on your communication - whether written form or verbal. Write clearly using full sentences. Be mindful that others may not have the context you have or don’t have the expertise you have in a specific. In fewer words, you want to convey a clear message.
Being able to communicate and break down complex topics will natural help you build influence and promote yourself in your career. The leaders will come to you for your judgement.
I see a vast number of posts on HN about React or some other web framework.
There’s more to software engineering than learning the latest flavor of how to render webpages.
Many projects don’t require the complexity of these frameworks and all the added middleware and layers upon layers of tooling.
These are bored people, who solve the same problems again and again, and invent new forms of complexity as if they’re undertaking the Gemini missions or Apollo missions.
It’s less about frameworks or specific tool chains. The biggest piece of advice I can offer you is to get out of your comfort zone, and learn to manage complexity and ambiguity.
This is what I didn’t know earlier in my career.
It’s not so much about quickly learning whatever new framework to once again solve the same problem people have been solving for decades. It is, however, about simplifying complexity, and thinking about how you or your team will support something in the future, will your solution be extensible as and when your product evolves, etc.
Work on projects where you solve problems that are hard to you. Work with more senior people whenever you can. Learn from them. Get comfortable with being out of your comfort zone.
But don’t burn yourself out. Drink water. Exercise. Don’t let your job become your identity.
Also, work on your communication - whether written form or verbal. Write clearly using full sentences. Be mindful that others may not have the context you have or don’t have the expertise you have in a specific. In fewer words, you want to convey a clear message.
Being able to communicate and break down complex topics will natural help you build influence and promote yourself in your career. The leaders will come to you for your judgement.
Technical communication is really important and you get good at it with time, practice, experience and feedback. I define technical communication as a skill to explain any project to a fellow engineer. Either in person or in the form of a written document. This will help you understand your projects more clearly and also in future interviews where you will have to explain what you achieved in the past.
Common security principles and how they are applied in daily use. For example Root Certificate Authorities and how they apply to having https://your-domain.work.securely with no browser errors. Using bought and certs created by openssl command.
> What is something that juniors are often not aware off. Something they don't know they don't know?
The key is to keep on asking this question about every project you work on. The world is made up of innumerable little complexities and the faster you reach out for guidance on each domain the better.
The key is to keep on asking this question about every project you work on. The world is made up of innumerable little complexities and the faster you reach out for guidance on each domain the better.
Even though I had great internships and lots of early startup experience, what I wish I learned earlier was how to simply deliver reasonably with my current skill-level and use that to level up in an org. I'm much better with this now, but it pains me to realize I have friends that have now leveled way above engineering and have made it into management positions and I'm just sitting here as a senior + engineer at a loss for words. When I'm deeply interested in what I'm doing I can grind 18hrs a day like nothing and crank out really cool shit, but when it's not interesting I basically resort to scrambling to re-position or coast. If I actually developed decent leetcoding ability I'd like to think I could start avoiding this pattern?
In software engineering there are always trade offs between approaches. There are no silver bullets. Context matters. OOP vs Functional, Monolith vs micro services, DRY vs duplication, Unit tests vs integration tests, and on and on. Don’t blindly adhere to what is claimed to be the best way or the right way to build software
Read books like Designing Data Intensive Applications. As you encounter stuff you don't know stop to Google it.
Always remember the Pareto Principle, you will find it applies to most aspects of life. https://en.wikipedia.org/wiki/Pareto_principle
It's easy to get the wrong solution from this though.
For example, 80% of my time is spent building my hard skills, which accounts for 20% of my income. Network, negotiation, politics accounts for 20% of my time and 80% of my income.
Do I spend all my time sucking up to people? No, nobody wants to deal with that kind of person. But I have to spend somewhere between 1-20% on it.
For example, 80% of my time is spent building my hard skills, which accounts for 20% of my income. Network, negotiation, politics accounts for 20% of my time and 80% of my income.
Do I spend all my time sucking up to people? No, nobody wants to deal with that kind of person. But I have to spend somewhere between 1-20% on it.
It’s easy to get this sort of information from people more experienced in what you’re trying to learn. I would ask around because that’s the easiest way to get the best answers without having to do a ton of research.
Pair with more experienced programmers.
I would even say pair with similarly or even more jr programmers as knowledge aren't subsets and trying to explain something really makes you learn it. Do be careful to not say things that you've read but don't understand, or if doing so state it as such.
All of the highest paid jobs don't care about technologies, they care about data structures, algorithms, and leetcode
You're getting down-voted but this is true. If you want to make more than $150k base and anything TC wise over $180k and you aren't some kind of prodigy the leetcode grind is sort of the best way there... especially in big cities.
You still need to get an interview in the first place though.
People on Blind are more than happy to give out referrals to people they don’t know.
Referrals don’t mean much if more than a small fraction of candidates have one
Thanks, that's something I never heard about.
Now my question: With experience, what do you think is important as a software developer. What is something that juniors are often not aware off. Something they don't know they don't know?