Ask HN: How can I grow as an engineer without good seniors to learn from?
I was hired 6 months ago as a freelance data engineer, and after proving myself through my work quality, I am now essentially functioning as a tech lead, with full responsibility and ownership of designing, implementing, and hiring for the projects I'm assigned.
Our company is not a tech company, so I only have a couple of tech-oriented colleagues, and I barely interact with them. Now I directly report to the director of the company, who in all senses is awesome, with 40+ years of combined experience in some of the biggest oil and drilling companies globally.
However, I have some strong FOMO about not being able to learn much technical stuff from my peers or seniors. I am trying my best to learn and pick things up on my own, learning design principles, getting code reviews from chatGPT, etc. But even then, I'm afraid I am not producing the software to the highest standards of the industry since we don't have any rigorous cross-checking, and might be missing out on a lot of learning.
Can someone who has been in positions similar to these please guide me?
303 comments
[ 5.4 ms ] story [ 403 ms ] threadIf technical proficiency was all that important to your employer, you probably wouldn't be in position you're in.
This 100%. It seems that you're doing things proficiently enough to keep your job, but just want to improve your capabilities as a coder. It's going to be difficult without a proper structure or mentors around you. So you've to make a decision whether you'd prefer to stick with the role and get slowly better over time using blog posts and AI reviews, or jump in the deep end and get another role in a more tech industry aligned company. And if you decide to jump to another role, just be aware that you're going to spend 3 to 6 months panicking about whether you're in over you head, and probably won't get "comfortable" in the role for a year.
YMMV, though. Some data engineers are writing basic SQL or playing with Azure Data Factory and there isn't too much complexity. Read Designing Data Intensive Applications. If that sort of thing resonates with you then find someone to work with who has experience with those kinds of problems!
[Edit: no disrespect to ADF! Just pointing out that the data engineering discipline is broad and different practitioners will have different expectations of complexity]
Perhaps they feel equally isolated.
Where in the world are you? That determines your options.
Read and study and learn from your mistakes and the mistakes of others – you will believe things and realize later that your beliefs were wrong.
If there was one book I had to recommend that I have read it would be Sandi Metz's 99 Bottles series.
Oh, and learn multiple programming languages.
Let go of FOMO, youth is the only reason you think it is possible to not miss out. You have and will miss most things because they were not hit your way. The only things you can actually miss are the opportunities that are yours.
But the only way to miss them is because your attention was somewhere else. You have an awesome opportunity for a mentor in the director. You caught a lucky bus, stay on it.
Right now people can look at you and see potential. In just a few years, they will look at you and see squandered potential. Sure technically you are an adult, but you have almost zero adult experience (your mentor has forty years of adult experience). Good luck.
However, if you learn well by doing, or by reading, there are loads of other great ways to improve technically. I’ve made big leaps forward in my skills by building (relatively large) side projects, where I can safely experiment with different design decisions and see the consequences over time. I’ve also got a huge amount out of just sitting down and reading the docs for tech I’m interested in - some frameworks (like React) have fantastic resources that can take you from good to great.
Good luck!
Ask them what the original goal was, how that changed, what proved to be important, what was unexpected.
Find some software that helps your company, and don’t be afraid to dive into the codebase. There may be times you can even contribute as part of your job.
Open source projects maintainers very likely have their own day jobs that are unrelated or only marginally related to the projects, have different priorities or just don't care enough. A previously important feature that has seen lots of activity may be on the shelf, but that's only known among maintainers with no public notes. You don't get to go into meetings or just send a Teams/slack message to get a quick response, let alone a casual chat at the coffee machine.
Unless you are working on prioritized features on a project like linux, VSCode or Chromium, chances are that your issues or pull requests go in the log until someone works on it months or even years later.
Speaking from real experience.
I am self taught and had no mentors for the first decade of my career. During that time I did things nobody else could do, things I was told were impossible.
Eventually I read some books and they added useful tools.
Read all the books from SICP to Superintelligence (ie concrete to speculative fiction).
But nothing is as educational as putting what you read into production, or putting it into production and fucking it up. I’d rather work with someone who has deleted a production database (ideally a preproduction database to be fair) than someone who hasn’t.
1. Learn how to learn well, continuously, and sustainably. Tech changes rapidly. And you will want to hop from one domain to another, just for keeping things interesting and to move with markets. This is both a blessing and a curse. It is a blessing because you can start late and still be in the top percentile if you have the brains and work hard for it. It is a curse because you will be doing this no matter how many years of experience you have.
2. Hone your non-technical skills– caution: these are compounding over time (both good and bad habits) – being disciplined, thinking clearly, articulating clearly, being professional, being trustworthy, managing your physical and mental health, being dependable/reliable, having a growth mindset, thriving in ambiguity and uncertainty etc. then, honing your communication skills – effectively collaborating with people, give/receive effective feedback, do/get mentoring/coaching, working with cross-functional people, working with very seniors, very juniors, peers etc. read a lot, develop mental models, deeply craft your personal approach to first principles problem solving, to making tradeoffs/bets etc.
You can do the above all by yourself, through reading, and observing people from afar, and engaging with people (even strangers on forum like this one) in dialog.
To make that more actionable... My approach in life has generally been to find a project (even something seemingly incredibly dumb, as long as it is fun), then work through it, learning what I need to know as I go along. To learn "well", you must then also constantly question what you have done as you complete various stages of the project to see if you have done them as effectively as possible, and try to incorporate any lessons learned into future projects.
I have found that how individuals do the learning required for this differs significantly from person to person, so it is hard to recommend any particular approach.
For example, I discovered early on that I learn in three phases: 1. I get exposed to something (a concept, a process, etc); basically discover that something exists. 2. I then see how that thing is used whether through mentorship or tutorials or, increasingly, through trial and error. 3. I apply that thing to some novel problem.
Through this cycle of Discovery-Tutelage-Application, I can assess my level of comfort with new material and understand when my struggles are due to trying to short circuit the process.
It's likely that you have some form of learning process that is equally cyclical, yet undefined -- once you identify and codify those steps, you can evaluate your progress when it comes to acquiring new skills.
Then in a regular work I explicitly detect where it pays off and feel “see I told you”. This creates a motivational loop to continue not-adhd-ing through tech.
Sometimes I still fly over the knowledge, but then may note that what I’ve been doing in a complex way could be solved with one parameter, if only I knew about it. This creates negative feedback against flying over.
This is ofc only one facet of learning, but I find this “see I told you” method very effective, cause my main issue with learning is unwillingness to learn for no clear reason.
Now, I mostly actually enjoy doing this and thus it has not really limited me. But I wish I could just spend some actual work time on more ‘non adhd-ing’ what I learn.
Sadly I'm now so easily burnout that even setting a dev env up can burn me out.
https://www.coursera.org/learn/learning-how-to-learn
I am not sure there's any hand holding that can be given to someone to learn how to learn.
https://www.coursera.org/learn/learning-how-to-learn
In code you don't have all the extra communication avenues that we have when speaking, like body language, intonation, sarcasm and so on.
On the other hand, when writing code we are not speaking in real time. We can think about a problem for a while, consider the best possible way to solve a problem and how to explain it.
What do you see as a big difference?
(3) Communicating clearly is an orthogonal skill to coding clearly. I think this skill is barely acknowledged in engineering cultures in comparison to the above.
I feel you have to have an engineering culture that values institutional knowledge retention, team education and growth — and not treating engineers as fungible — to get to level (2). Level (3) would be a great place to work.
There's keeping the engine well maintained (the sleep and exercise part, for example) and there's driving the engine down new paths and honing you driving technique. You work on the latter by exposing yourself to novel and interesting arguments (interesting philosophy or argumentative non-fiction, for example) and then working through the argument again with counter-arguments in mind. I would not recommend pop-sci books for this, because their arguments and writing tends to be quite flabby.
I'd actually recommend something like RG Collingwood's "The Principles of Art" which is a relatively plain English example of well written philosophy:
https://archive.org/details/in.ernet.dli.2015.188470/page/n1...
You will disagree with him. The point is to understand how and why you disagree with him and to explain that clearly, not only to yourself but others as well. Thinking clearly is about responding and communicating clearly while displaying a sure and succinct understanding of the problem at hand.
You can apply that to everything you read or are confronted with, but the key thing to realize is that "thinking clearly" is something you practice. There is no one trick --- it's an approach.
Taking a complex domain and effectively communicating it (correctly) at different levels requires having not just rote knowledge but an actual understanding.
Practical tips on learn good techniques, do research, find the best tech companies that do similar development to yours. Check out their technical blogs, their githubs, find opensource projects which have been developed to the highest standard. Dig into them and potentially even rewrite your own simple versions to learn, maybe twin it so you could make the new implementation a part of an internal research project... so main possibilities there.
It is so valuable to take the ideas and questions in your head and get them out. You can then have Claude interrogate and problem solve with you.
By default, I think Claude is very conservative and sometimes comes up with ideas that aren't quite right. But you can actually just tell it to be less concerned about X or Y, to start over from scratch, etc.
Another trick I use is to ask it to ask me one question at a time to help clarify my thinking. I find that the one by one questioning really helps me find the boundaries of my knowledge and crystallize my opinions.
What I did:
* Read. All the things. Read HN comments, read tech blogs, read books. Don't put too much weight on any single book/comment/blog post—they'll almost all disagree with each other, and you'll learn the most by comparing and contrasting all of the strong opinions rather than uncritically absorbing any given opinion.
* Be okay with using work time for professional development. Your employer hired someone they knew wasn't experienced into a role that is typically filled by someone more senior. They need to be okay with you learning on the job, and if they're not you need to go somewhere else.
What I wish I'd done but failed to do:
* Don't get overly invested and burn out. This is your first job, but it's not your life, and your career doesn't depend on you completely blowing it out of the water as a brand new developer thrown into the deep end. Don't overinvest.
* Keep your eye out for red flags. Tiny companies that can't hire seniors might be small and niche but sustainable, but they might also stay small because the business side of things just doesn't work for various reasons. In my own case, it turned out the founders of the tiny company were both narcissists (which seems to be a common problem with tiny companies), which led to a ridiculous political implosion that I was lucky to escape.
Join Discords related to the stuff you’re working on, you’ll find people much smarter than you and any of your colleagues hanging out, talking about good approaches to designs, structures, infrastructure, etc.
You’ll also find idiots not worth listening to.
Remember you’re 6 months in / just doing the job is enough of a challenge. You’re calling yourself a lead for having full responsibility of the projects you’re working on. This is typically common everywhere except large tech companies.
You can learn from everyone around you, regardless of their status. There is no "universal developer experience curve", everyone has more or less knowledge on a field or with a specific tool/framework.
You can learn almost everything alone - I mean learning from the web. There are great forums, groups, discord chats, ask LLMs carefully and check on the answers. It may sound reassuring that someone watches your back and won't allow mistakes or would help clean up a mess, but you should not keep relying on this anyway. Learning by doing and taking responsibility will make you much more self assured, which is actually most of what makes someone senior.
You can have bad mentors/seniors, but looking for people to learn from and bounce ideas off is always a good idea.
Having a good mentor or two is pretty essential because most of knowledge isn't written down and retrievable by LLMs or about some framework or tool. It is the experience of people who have been there before, done it, got burned and learned to not do the same mistake again.
It might be a personality thing though. I’m a stubborn idiot who questions everything he’s taught. I don’t take advice. I listen to people stories. The why has always more important than the how.
I’ve been fortunate to have many teachers and mentors, but I didn’t seek any of them out and none of them guided me. They were people with the right perspective and I had asked them the right questions.
But the two best mentors in my life are my two best friends. All three of us are different and have different things to teach each other.
But if you are the only technical person around, who is going to show you what a good or bad practice *in your specific field* is? That you won't find on Stack Overflow or by asking ChatGPT.
Being able to talk to an experienced mentor who knows the field you are working in is invaluable. Unlike learning some framework or design patters or what not, this information you won't find anywhere else.
I've found that one of the harder aspects of being unguided is figuring out the unknown unknowns.
You might stumble into a solution of sorts that mirrors a best practice but not know there's a "name" for that solution -- until you see it spelled out after googling around. That discovery can lead you down a rabbit hole where you gain fuller context.
Sure, having more experienced people around can help expedite that process in some cases, but then again you're limited by what that person has experienced. There's always some level you reach where you need to be curious enough in your explorations to seek out the next layer of knowledge in a self-directed manner, and the tools today are immensely better at supporting that process than 10-15 years ago.
any more im missing?
Fuzzing is only really useful for a very narrow range of analysis scenarios. If people understand threading properly: code should be able to take getting hammered, exiting gracefully, and cleanly get re-instantiated.
Also, banning hosts/accounts with an error-rate quota system is more common these days. =3
this trend in programming culture reduces our ability to do automated error detection!
you make a good point, and a good case for crash early and crash often -- with choice of erlang style recovery, or fuzzing style hard nosed correctness enforcement
But I think there's a difference between someone who 'teaches' you and someone who is at a high enough level to discuss ideas or issues with you.
For example, in my first job I 'learned' the most not from the senior engineers around me but from another new grad who was just as curious as me. We would discuss issues we're having, brainstorm solutions etc. It was not so much that I learned from him, but that I had another brain of similar competence that I could fling ideas at.
Not having such a person makes your job more difficult (as you might find yourself in a rabbit hole and desperately need someone else's perspective) and much less enjoyable.
Imagine not having a competent dev in your team to review your code.
is not a fallacy because it doesn't work, it's a fallacy because such teams rarely exist. I have worked on one or maybe two such teams in my career, but the truth is to get on a team like this you already have to be exceptional.
If you require a team of elite experts that are not only technically excellent but also love teaching untrained juniors in their ways, then you it may take you longer than the typical span of such a career to find these people. Then, even if you do find such a team, they're extremely unlikely to take you under there tutelage unless you yourself show an impressive potential to learn. And people that are truly exceptional don't wait for the right teacher to start learning.
I started tutoring my roommate in college, and random people in the computer lab while he was finishing his homework. So I’ve been doing it longer than I’ve been professionally programming which is a long time.
https://onlineteaching.umich.edu/articles/the-myth-of-learni...
There's a good back about how to learn effectively written by cognitive scientists:
Make It Stick: The Science of Successful Learning by Henry L. Roediger III, Mark A. McDaniel, and Peter C. Brown
Definitely worth a read, even reading a summary on the book would be beneficial if you want to become a better learning. The techniques in the book work IME.
Throughout the book you keep hearing stories about how application and spacing are critical for reinforcing concepts.
I don't have it in front of me but I remember they presented one study that students who took a practice exam did better than those that just read the material and took the exam.
In the book they mention often that rereading material isn't useful or an effective way to learn.
Spaced "repetition is the mother of learning" is what my parents always told me. Minus the "spaced" part.
And yes, that's how we learned for most (good) university courses. We had "labs" every week. It was non-mandatory and while some profs would give you credits towards the final grade if you took part in them, the idea really was to get you to practice things over and over with some time in between. By the time you were learning for the final exam, it was already at least the second or third repetition of applying the knowledge.
Reading docs (or the book / your lecture notes) when trying to apply the knowledge is OK. Just reading it multiple times but not actually trying to use it really doesn't do anything in my experience. I passed my initial "learn a programming language" course at university without ever going to a lecture past the first two for example. I was using said language to actually build something that required what I knew was gonna be the main part of the exam (boolean logic - duh - and concurrency - way more fun) for building some actually useful tool for a friend.
This assessment totally devalues the experience of having an more senior, more capable colleague to learn from. They are not there to watch anyones back, stop mistsakes, or clean up anyones mess. Rather the point is that the junior member is able to watch the senior person, observe how they solve their problems, and how they approach fixing their own mistakes. It's about tacit learning, not bein nannied/micromanaged.
Watching a senior is not a senior pointing you to pitfalls, or unknown unknowns.
The parent argues that although there is value in being near a senior, all the actions lay with the junior. This is a transition people need to make when they leave school and enter work.
There's a big difference between learning from someone and having someone teach you something. The latter expedites your progress and clarifies learning path, whereas the former can even waste your time with political fights pulling you into dead-ends.
Keep fighting the good fight.
I would like to stress that your employer should, and will likely be happy to pay (or give you the time) to do many of the following. Don't feel like you need to do all of these by any means, I just wanted to give you everything that came to mind that has helped me in my journey:
- Conferences both in your specific domain (in your case oil and gas), or your specialty, like a more general data science conference. Meet people there and keep in touch with them, both fellow attendees and also speakers and people who have booths there. Your employer should be cool with covering one or two of these a year. If they're reluctant or on the fence it has helped me in the past to writeup a little summary of the conference, what I hope to learn and how it apply to my work, and give them a written summary when you get back including concrete things that you learned that will help your company pragmatically.
- Meet mentors on platforms like this, foster and build those relationships. It seems like you are already doing this well. Other places to meet them are at local and virtual meetups for the software or packages you use, tools you use, industry societies, etc. Linkedin is also an underrated and underutilized tool for this IMO.
- Free or low cost remote courses. I'm just wrapping up a remote class at Stanford, it's been awesome. Many universities offer courses, or even course materials and videos you can get your hands on. Good universities, with good courses.
Do these things during the work day, because they are work. Don't think like you need to do all this stuff above and beyond. Any good company should be investing in you.
-