[HN Gopher] How can I grow as an engineer without good seniors t...
___________________________________________________________________
How can I grow as an engineer without good seniors to learn from?
I am a fresh graduate data engineer working at a small company in
the oil and drilling industry. 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?
Author : prathameshgh
Score : 64 points
Date : 2024-12-01 18:56 UTC (4 hours ago)
| jqpabc123 wrote:
| If "technical stuff" is your primary interest, you should
| probably consider changing jobs.
|
| If technical proficiency was all that important to your employer,
| you probably wouldn't be in position you're in.
| Simon_ORourke wrote:
| > If "technical stuff" is your primary interest, you should
| probably consider changing jobs.
|
| 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.
| l00sed wrote:
| "AI reviews" is actually a really interesting use-case that I
| hadn't considered-- but makes so much sense. I feel like it
| might be good to use Cursor or another AI assistant just for
| the purpose of suggesting improvements rather than a way to
| code quicker.
| donall wrote:
| Strongly agree. I have been doing data engineering for 14 years
| and, in my experience, new grads need a lot of on-the-job
| training. There are a lot of real-world problems (e.g.
| consistency problems, scale problems, distribution problems)
| that benefit from a little bit more than just theoretical
| knowledge. A lot of data systems are full of problems because
| they were designed and implemented by inexperienced people.
| People don't know what they don't know and there are a lot of
| teams that say things like "oh yeah, this takes 3 days to run
| because it's pretty big" or "we release code daily but it would
| be too expensive to re-process past data to fix bugs" or even
| "what's a schema?".
|
| 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]
| BurningFrog wrote:
| Maybe you could try to informally get together with the other
| tech-oriented colleagues.
|
| Perhaps they feel equally isolated.
| sneak wrote:
| It sounds like you are doing better than many in corporate jobs;
| you are being proactive. ChatGPT is quite valuable here, as is
| studying.
|
| Where in the world are you? That determines your options.
| ediri_aghwotu wrote:
| True, I think Claude would be a better choice.
| syndicatedjelly wrote:
| I was in this position for a few years in my first job, and I
| ended up quitting for exactly this reason. It's important to
| surround yourself with technical experts early in your career,
| lest you fall into the "expert beginner" trap
| (https://daedtech.com/how-developers-stop-learning-rise-of-th...)
| jweir wrote:
| I am primarily self trained and it took a long time to get
| "good". I wish I could have worked under a master, but that
| opportunity never arose and I was starting when web development
| was all new - so there were no masters.
|
| 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.
| RandomWorker wrote:
| Getting thrown into the deep end is awesome. This is a great
| opportunity to apply things you can learn. Keep studying and
| reading, ultimately solving problems even not perfectly you will
| learn a lot.
| brudgers wrote:
| Grow in the areas that are open to you. People skills and domain
| knowledge. These are the foundation of a career.
|
| 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.
| greysteil wrote:
| I've found that everyone learns in different ways, and if having
| mentors / seniors to absorb knowledge from is how you learn best
| then I'd agree with the comments suggesting you change roles.
|
| 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!
| raggi wrote:
| Read and write a lot of projects. Early career you need to get
| out there and see things. If you find stuff others are working on
| too all the better (e.g. OSS but there are other things like
| charity or public projects too)
| invalidopcode wrote:
| +1 for _reading_ projects. There 's rarely one, perfect way to
| solve a problem, and there's certainly no silver bullet pattern
| in software. The more patterns and types of solutions you've
| seen, the bigger the set of tools you'll have in your mental
| toolbox when faced with a new problem.
| jonwinstanley wrote:
| Also, try to find people to speak to that have built major
| projects.
|
| Ask them what the original goal was, how that changed, what
| proved to be important, what was unexpected.
| VirusNewbie wrote:
| I learned a ton from contributing to large open source projects.
|
| 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.
| n144q wrote:
| It is unfortunately not efficient compared to what you get when
| working with actual colleagues within a company.
|
| 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.
| danjl wrote:
| Why not look for a job with a established development team? I
| cannot imagine how anything could replace the experience you get
| from working directly with other developers. You will learn more
| than just technical skills. You'll learn more about how to
| predict time estimates, how to interact with other groups in the
| company, how to set up good infrastructure for development,
| deployment and support. If you learn all these things yourself,
| you will make lots of mistakes along the way which can harm your
| current employer.
| aerhardt wrote:
| There's great value in quality technical mentorship, but
| they're trading it off for an opportunity to learn leadership,
| autonomy, and cross-functional skills at a very fast pace...
| That's not a route for everyone but it could be a massive
| opportunity for the right person.
| lowbloodsugar wrote:
| There's no better teacher than running code in production.
|
| 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.
| jonathanrmumm wrote:
| Try to forget the mindset that you need an authority in order to
| learn. Better to pretend authorities do not exist.
| ilrwbwrkhv wrote:
| Open source is your friend. I wonder why more people do not take
| advantage of it. It's one of the greatest hacks available in our
| industry. Imagine in other industries like if you wanted to be a
| doctor, he could be a part of someone's greatest surgeries in the
| world like that is the power of open Source. Choose a project
| that you like lurk for some time, learn the styles and idioms of
| the project and then start contributing and take the feedback
| that you get seriously and improve upon it.
| vinay_ys wrote:
| Couple of important lessons that will keep you in good stead for
| a long time:
|
| 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.
| newfocogi wrote:
| How do you learn how to learn well?
| emusan wrote:
| This is a difficult question to prescribe an answer for that
| works for everyone, but the best I personally can think of is
| "practice".
|
| 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.
| christoff12 wrote:
| The key is to figure out what your learning process looks
| like.
|
| 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.
| tmitchel2 wrote:
| It sounds like you are in an awesome position where your
| management respect you and your work output. This most likely
| won't be the case in all positions you take throughout your
| career. Leading projects are a great way to learn after making
| mistakes, you also get to set the direction and get the rewards
| when things go right.
|
| 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.
| ThouYS wrote:
| copy the works of masters. that means look at it, think about it,
| put it away. And then, on your own, try to recreate it
| CityOfThrowaway wrote:
| Even as a very experienced engineer, I find that I learn a ton
| from chatting with Claude about technical decisions.
|
| 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.
| lolinder wrote:
| I was in a similar situation right out of college, and it worked
| out for me in the end. After I moved on from the tiny company I
| was terrified that I wouldn't have the skills needed to succeed
| in a "real" company, but I was pleasantly surprised to find that
| I actually _had_ learned a ton and rapidly became one of the most
| senior engineers on my new team as well. So: it _can_ work.
|
| 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.
| throwawayian wrote:
| Find mentors. This is true of any tech field.
|
| 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.
| subarctic wrote:
| Having full responsibility for the project, sure, but having
| the authority to hire for it is rare
| poisonborz wrote:
| Craving for a team of more senior people to learn from, "yodas"
| who guide you - is a fallacy. I hear younger people mentioning it
| in interviews constantly as to what they dream team would look
| like.
|
| 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.
| Arainach wrote:
| Learning by yourself is (on average) significantly harder. Some
| people can do it and succeed, but it's very easy to learn bad
| habits if no one is talking you out of them, to focus on the
| "fun" parts to the detriment of important but tedious parts,
| and so on. Far more people who attempt to be "self taught" fail
| than become incredibly successful.
|
| You can have bad mentors/seniors, but looking for people to
| learn from and bounce ideas off is always a good idea.
| noobahoi wrote:
| Well, it's harder, but I don't think it's too hard. You have
| to keep your motivation high.
| janoc wrote:
| Good luck with that when you are not at the stage of your
| career yet to have enough experience to judge what is good
| practice - and what is hype, BS and liable to cause problems
| for your project.
|
| 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.
| kayodelycaon wrote:
| I can second this. I have learned infinitely more by doing and
| teaching than I ever have from being taught.
|
| 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.
| janoc wrote:
| It is not about "being taught".
|
| 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.
| christoff12 wrote:
| You'd be surprised at how useful Stack Overflow and ChatGPT
| can be at helping to illuminate knowledge gaps.
|
| 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.
| hstojkoski wrote:
| I think the OP you are replying to points to "you don't
| know what you don't know". SO and ChatGPT can be useful,
| if you know what you are doing is fishy and ask for
| directions.
| qnleigh wrote:
| Read documentation? Oftentimes you'll get a much better
| understanding of something by going to the source than by reading
| quick how-to's and Stack Exchange. This certainly goes for Python
| and Git.
| gompertz wrote:
| Personally I find a good linter like SonarLint can actually teach
| you a lot.
| iancmceachern wrote:
| I've been in similar situations.
|
| 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.
|
| -
| ryukoposting wrote:
| You aren't alone. Plenty of "actual tech companies" don't have
| the tools to develop talent effectively. You're owning technical
| features and you're reporting to high-level leadership. That's a
| great spot to be in.
|
| It sounds like you have the initiative to push your own
| boundaries, and that's what matters most. No matter where you
| are, learning starts with your willingness to learn.
|
| I'll admit I've never been in your position precisely. I've
| always worked with technical people, even if not for "tech
| companies." But, before I had even graduated I _was_ the only
| person in my entire company doing mobile dev, so I know what it
| feels like to be very green, and _very_ far out on your own
| island. It was a great springboard. I never did mobile dev full-
| time again, but I experimented and explored stuff I found
| interesting, and the skills I learned have been invaluable to my
| career.
| __alexander wrote:
| Curiosity. Books. Projects. Presentations. Hosted personal notes.
|
| That's it.
|
| Read books to understand fundamentals. Create projects to
| practice and expand on the fundamentals. Watch videos to learn
| how others solved problems. Document your learning. Repeat.
| faebi wrote:
| Go to a few meetups, maybe you can find some peers in your area.
| joshdavham wrote:
| Open source is a great option.
|
| You'll get to work with others who are more senior than you and
| see how they do things. It's definitely helped me a lot.
| bitwize wrote:
| Find a tech group in your area to join, and participate in
| discussions or just listen, as you see fit.
|
| I find that it is refreshing to hear the perspectives of working
| and aspiring programmers, and I stand to learn a lot about the
| field outside my little bubble within it: what various startups
| are doing, the problems they're trying to solve, etc.
|
| In short, if you cannot find humans to talk with and bounce ideas
| off of at work, do so outside of work (but be careful about your
| company's trade secrets, etc.). Do not rely on ChatGPT. ChatGPT
| is to discussion what ultraprocessed food is to food.
| svilen_dobrev wrote:
| Apart of specific domain-related things (geo, physics, mapping
| etc) , read general software books. Maybe some philosophy too..
| as software is (medium of) knowledge, and studying knowledge is..
| philosophy. Winnie the Pooh and requirements-engineering?
|
| Find other people working on similar/related topics, connect with
| them, offline or online. Do not fear being THE Tech Guy in the
| company.. just do not be over-confident / arrogant. Doubt quick-
| wins, check, prove things. 30 years ago such one-programmer-per-
| company was a normal thing.
|
| My reading recommendations are below, but that's just what i have
| found good.. not exhaustive list. i found some of those only
| after 11 years doing stuff by myself, and saw i have been
| inventing hot-water in many "wrong"-but-somehow-working ways, so
| what.. Better than only applying miracle recipes you don't
| understand.
|
| https://www.svilendobrev.com/rabota/
|
| https://www.svilendobrev.com/1/
|
| And, most important, have fun!
| noobahoi wrote:
| Of course, it's nice to have some seniors, where you can look
| over their shoulders. Usually, you don't have this ideal
| situation. Most of the time, I didn't have it, too.
|
| You can use a lot of modern Internet resources.
|
| I got a Learning O'Reilly Account. There you can find courses,
| videos and live events where you can ask questions. It's helpful.
|
| Read a lot of good books/e-books, ask in forums and maybe in your
| town is a user group for that.
|
| Just write the software and constantly look to improve. Your code
| from 2 years ago is in an ideal situation, much worse than your
| code now.
| ucefkh wrote:
| You gotta stay up to date with the lastest and greatest
| janoc wrote:
| If you want to grow you will need to change jobs. Small companies
| are not a good fit for a fresh grad with little to no experience.
| In a small company you are by necessity a jack of all trades
| because there are only so few of you.
|
| If you aren't experienced already it is a very hard position to
| be in, with a huge responsibility and potential to screw up due
| to inexperience - and be promptly thrown under the bus when the
| proverbial shit hits the fan. Code reviews by ChatGPT can't
| compensate for lack of more experienced colleagues.
|
| The best way to grow as a fresh grad is to join a medium sized,
| established business. There you are going to be a part of a team
| where you will get to learn the ropes of your field (that's
| something you won't find in ChatGPT or university) and at the
| same time the pressure won't be so hard. And while you aren't
| going to get the perks of working at huge companies like Google
| or Facebook, you likely won't have to deal with assorted
| corporate BS that comes with it either.
|
| Only once you get a few years under your belt think about
| startups, small companies, etc.
| aleph_minus_one wrote:
| > If you want to grow you will need to change jobs. Small
| companies are not a good fit for a fresh grad with little to no
| experience. In a small company you are by necessity a jack of
| all trades because there are only so few of you. [...]
|
| > The best way to grow as a fresh grad is to join a medium
| sized, established business. There you are going to be a part
| of a team where you will get to learn the ropes of your field
| (that's something you won't find in ChatGPT or university) and
| at the same time the pressure won't be so hard.
|
| My experience differs: already at medium sized, established
| companies there is a lot of corporate bullshit. Also, at small
| companies, you know the colleagues better, so that the culture
| is often more "humane". Also, exactly because at a small
| company you are a "jack of all trades", you by necessity learn
| a lot more; but be aware that on the other hand you won't
| specialize so deeply into the topic. So, if you want to deeply
| specialize in a topic, you better look at a medium or large
| company (but be aware that there might exist few or no jobs
| there that allow you to specialize in the topic that you are
| into).
| gwbas1c wrote:
| Ideally, you need to move to an entry-level position within a
| year or two. Don't plan on staying in your job very long; no more
| than 1-2 years.
|
| Why?
|
| I once encountered a tech lead who was at the same job, since
| graduating, for about a decade. All of the novice mistakes
| showed. Because there was no one there to correct basic security
| mistakes, the lead grew very accustomed to getting their way and
| getting constant flattery in the process.
|
| When the time is right, seek a position where you're generally
| the most junior employee, and seek to learn from everyone around
| you. It's important that you can learn from others before you get
| into a leadership role.
| szundi wrote:
| What I do while being a CEO and not engineering anymore is to
| always entertain some interests in engineering. This is easy for
| you as you are actually working on something. In my case it was
| always the biggest challenge of the engineers of the company.
|
| I've spent my commute time to learn about these topics from
| youtube. For example watching EEVBlog or Uncle Bob or whatever.
| Then stop sometimes and just think about it regarding my past
| experience. Replay the stuff that I lived through while thinking
| about what I heard. Then find my best colleagues and sincerely
| ask them what they think about what I was concluding just then.
|
| Also I like Twitter/X after just muting/notinterested-buttoning
| the people who just post idiot stuff. Then it is quite a good
| source of ideas about the present mainstream - that's also very
| important.
|
| But the most important: never forget while swimming in ideas and
| memes: take some minutes sometime to asses what actually worked -
| and what is that somehow never works for ... reasons.
|
| Great question on HN!
| codr7 wrote:
| I never had good seniors/mentors, but I do hope I manage to be
| one occasionally.
|
| It wasn't until I started going to conferences, Lisp/Python/Perl
| etc, that I actually met people with the same level of brain
| damage or worse than me.
|
| Both paths lead to the same place, having access to mentors gets
| you there faster I guess.
| medler wrote:
| I was in the same spot for the first few years of my career and I
| regret staying there as long as I did. It really is easier to
| learn if you have senior engineers to give you feedback. My
| recommendation is to find a new job.
|
| Failing that, I'm not sure what your relationship with your
| manager is like, but in most tech companies, part of your
| manager's job is to help you grow. Maybe they could help you
| reach out to the few other tech people at the company to organize
| some kind of collaboration to help you all grow and improve.
| rawgabbit wrote:
| Even when I was in large companies with over 10K employees, there
| were times due to internal politics I could not interact with
| more experienced folks. Truth be told, the difference between
| fresh graduates and seasoned people... is the more experienced
| people learned from the school of hard knocks.
|
| Most of which can be distilled into: _Don 't follow fads, the
| latest shiny tech; they will only break your heart and maybe ruin
| your career. You want to deliver a quality product that just
| works, never breaks down, and if it does it is easily diagnosed._
|
| What that means is (a) use software from vendors you can trust
| and have actual live support (this means they are usually
| expensive) (b) KISS. In a small shop you will be responsible for
| everything. You want as few moving parts as possible. You
| especially want to avoid all custom integrations; they suck. If
| software B doesn't offer an out of the box connector to software
| A which your company already is using. They are immediately ruled
| out. (c) never trust a salesman/saleswoman. Before you sign any
| contract, you want to try it out as proof of concept. Just
| because they say they have an out of the box connector, for
| example, does it actually sync the fields you want? Verify it
| works before signing any contract. If the salesman doesn't like
| it, tell them good bye.
| rich_sasha wrote:
| KISS actually means, sometimes write it from scratch yourself,
| which will save you time short-term and teach you great stuff
| long-term, rather than use the "industry standard".
|
| When setting up my current operation, I needed a job scheduling
| framework. I looked at Airflow, but by the time I had to choose
| a DB backend and create usernames and set up SMTP server, I
| gave up. In half a day I knocked together a basic single
| machine scheduler, which does 5% of what Airflow does. But it
| does that very well, took me frankly less time than setting up
| this behemoth, and works really well for my team.
|
| Is it better than Airflow, or Prefect, or whatnot? Surely not;
| but it saved me time and taught me a lot about job scheduling.
| rawgabbit wrote:
| [delayed]
___________________________________________________________________
(page generated 2024-12-01 23:02 UTC)