Ask Experienced Devs Weekly Thread: A weekly thread for inexperienced developers to ask experienced ones

[-]

Plus_Cardiologist540@reddit

How can I grow and learn things such as best practices when my team consists solely of junior developers (including myself)? Is reading books and blogs enough?

[-]

Eligriv@reddit

Read about stuff, then try it out in your work, then learn and adapt.

Also, read about generic programming stuff, not specific to your stack stuff. Like everything that Kent Beck wrote for instance.

[-]

boring_pants@reddit

That's a good start. Networking, as well. Go to conferences relevant to your tech stack, or programming meetups in your city.

You can also hire experts to do some consulting and training for you and your team.

Mainly, be curious. Seek out knowledge, and try to implement it for your team and see how it goes.

[-]

Serious response: Do not use AI, at all. Learning to dig deep into documentation and existing, industry-standard solutions is the only way to properly develop skills. I can send you a laundry list of studies that prove that using AI, at any level in any context, erodes your existing programming skills as well as your general critical thinking. Likewise, ignore the people telling you there are no "best practices", that is insanity.

Beyond that, reading books is a must if you want to develop the same mindset of successful senior developers. Blogs, no. The type of people that write blogs and create youtube channels are, as a whole, fairly low skilled and looking to create a career as a "consultant" for themselves in the future, or just trying to look good on Linked-In (ew). The most popular ones are incredibly low-skilled and survive because they appeal to anxious juniors who want a leg up over their peers. Ignore them, please, it'll do you good.

For general reading I would recommend:

Clean Code Clean Architecture The Pragmatic Programmer Learning Domain-Driven Design (by Vladik Khononov)

That should be a good jumping off point from which you should dive deeper into language-specific books and whatever niche you're going to be actively developing in. My last point, the whole "everybody learns differently according to their learning styles" is a myth and I hate that it persists because it actually has a detrimental effect on your learning. If you want to study in a way that is productive, as proven by cognitive science, you'll want to utilize the The Feynman Technique while introducing the following concepts into your learning process:

Retrieval Practice Spaced Repetition Interleaving (and one of the most important) Desirable Difficulty

Cheers and Godspeed!

[-]

Flashy-Whereas-3234@reddit

Technology is constantly changing, so there's a few factors that have worked for me.

Everyone learns differently and knows different things. Try out different techniques to see how you absorb information best. Some people learn better from podcasts, YouTube, talking to AI (it does work). Some people retain information better by writing it down, even if you never refer to it again, it gets "written" in your brain better.
Get annoyed. Necessity is the mother of invention, so when you implement something and feel that it's ugly, it's a good time to ask wtf. Redesign it again on paper, ask AI what you could do differently and why it annoys you. Talk to yourself, critique your work.
Learn from other code. Dive into the framework, run the debugger and go under the hood. Be interested. Where else have you seen things like this, how do they work? Games and game engines are an amazing resource, they've basically solved every problem ever, so they're fun to explode with an AI to help explain, or just watch one of those code review videos.
Talk to AI. This one's risky because it can make shit up and be too bias-confirming, but learning from books and videos is super structured, whereas AI is a little bit like having a slightly drunk professor who doesn't get annoyed when you ask the same questions from 3 different angles because you're just not getting it. If you have a specific gap, chat to AI and see if helps fill it in.
Opportunistic improvement. Don't try and bring every single thing you learn into work at once. When you learn a new tool, you're tempted to use it on everything, and that's never goes well. Keep your tools in your bag, and when it's cheap and quick to implement something new, give it a crack. Getting buy-in with other Devs is a real senior move and takes a lot of social skill, particularly if they're lazy learners, which is why opportunistic and light-touch applications are great ways to slowly move the needle on dodgy stuff.

[-]

_some_asshole@reddit

Great points. There are no ’best practices’ only best practices for the context you’re in

[-]

joranstark018@reddit

You need both theory and practice. You may for example learn about different design patterns and different architectural patterns for solutions to some common problems (you find tutorials/books and blogs on the subject). They still leave some room for personal taste so read, practice, reflect on the outcome and have discussions about the pros and cons of the different solutions with others (see what works for your team).

[-]

micseydel@reddit

I would start a personal private note-taking practice first and foremost, beyond that, I would value school and practical experience over books and blogs or YouTube.

[-]

Monsieur_Joyeux@reddit

Can it be sometimes acceptable to not being able to test a feature/PR in a local environment, but only on a production environment ?

[-]

Eligriv@reddit

It's a choice : you'll have to pay in money for a proper testing environnement and breaking dependancies or you'll have to pay in lost clients when you'll fuck up their data.

[-]

Elegant-Avocado-3261@reddit

I feel like I'm going insane. 3 or 4 months ago management was on our ass and looking at our cursor token usage and complaining we weren't using it enough. Now they're on our ass looking at our token usage and complaining we're using it too much. When will it fucking end?

[-]

Connect-Shock-1578@reddit

How do you handle other people touching your PR? Are there best practices around PR responsibility?

In my regular team we don’t touch other people’s PR unless explicitly asked to take over, as there may be planned changes or dependencies unknown to the person not on the task.

I recently partially joined another team to support them. I made 3 PRs stacked on top of each other (needs a 3 -> 2 -> 1 merge). Another developer in the team (who joined around the same time, we are both new - and they work mainly on another part of the project) closed PR1 without talking to me, citing duplication with PR3. It is not a duplicate, it is a dependency.

I reopened the PR but am somewhat irritated, because in my limited experience you don’t touch other people’s PRs unless discussed. For reference, even the lead of the project asks me to merge my own PRs after review “as you know the order and dependency the best”, so I’m not sure where this sudden closing came from and how to address it.

I’d like to hear others experiences on this, being aware of my limited experience.

[-]

navlaan0@reddit

Maybe it’s a work culture thing. I’ve worked with some very nosy and clueless devs, but I’ve never seen someone close another person’s PR without asking something like: 'Hi, is this a duplicate? Can I close it?'

Since you’re new to the project, have you noticed if others do that too? Assuming the other dev has the same level of experience as you, there’s not much to do besides explaining why it’s not a duplicate and reopening it. The realization of being corrected should be enough to make them more careful next time. If they are less experienced, it would probably be productive to talk to them and explain why they shouldn't close others' PRs; some people just don't know yet.

If the dev is more senior, I would ask someone who’s been there longer if it’s always like that, choosing my words carefully so as not to sound salty. These types of problems are the worst because they aren't worth fighting for, but if you let them slide too often, they become routine. Just be polite and explain your side.

[-]

davvblack@reddit

(i identify as experienced but have a good q for yall)

how do yall manage timeouts and retries in your system? for example a simple browser -> serviceA -> serviceB -> data. We have found it extremely difficult to build a system that’s more reliable than doing nothing at all, aka everything gets exactly one try with a long timeout, except for limited postgres statement timeouts.

we haven’t gotten as far as integrating a full stateful circuit breaker but that feels like a real and significant jump in complexity and maintainability (and who breaks the breaker?).

[-]

Flashy-Whereas-3234@reddit

Do as much Async and possible, sync should be used very strategically. Do you actually need a reply? No? Off to the queue with you.

Make your teams publish an SLA for API response times. I really do need to know if that API responds in 50, 500 or 5000ms.

Telemetry gives you unofficial response SLA.

I will absolutely slam the fucker if the SLA given to me is wrong, and it's your own fault if I over tax your infra and take you offline.

Exponential back-off, if the SLA says you have time for it. A sync API that takes 10 seconds isn't going to have much room for a retry on a web request.

Rate limiting if I'm feeling nice via some semaphore maybe redis, but neh. Probably just going to slam it.

Async, Async, Async. Change the paradigm of your designs.

[-]

latkde@reddit

At some point, such synchronous call chains simply no longer work, and you have to move to asynchronous patterns (e.g. message queues). This is a natural consequence of dealing with distributed systems.

For the communication between the browser and your backend, you can make HTTP-level timeouts irrelevant by using websockets instead, but doing this well can take a lot of effort (really depends on your programming language and web framework as well).

[-]

OtaK_@reddit

At some point, such synchronous call chains simply no longer work, and you have to move to asynchronous patterns (e.g. message queues). This is a natural consequence of dealing with distributed systems.

This is the answer. More accurately, a message queue thing that takes care of the Request->Response flow (for example, NATS is such a message queue). You'll get a natural timeout on your msg queue timeout, which you can bubble up at the http level. The only issue is partial writes; If you have a heavy call that actually mutates the database, you might get a timeout BUT the data has been persisted, which is a problem that can be addressed by cancelling the task in case of a timeout. Lots of hidden complexity on distributed systems :D

[-]

_some_asshole@reddit

Are you asking about retry back off semantics?

It really depends on your system. Is there a good reason why you might succeed when you do a retry when you failed the first time?

Are you retrying to spread load out over a quota?

[-]

Curious_Cantaloupe65@reddit

Recently got layed off, why am I having a hard time with codeforces contests? how to gitgud?

[-]

_somestupidguy_@reddit

Need insights if anyone has gone through the same scenario and how it played out for them in their careers.

I currently have 8+ years of experience. In which, 5+ in the automotive field, 3 yrs break for Masters and then 1 yr in automotive research and 2 years in aerospace. But more or less all work was related to embedded software development. And recently I gave an interview for an embedded software developer's role for medical equipment.

The point which is really bothering me is, should I focus on one single domain and gain more experience in it, rather than switching domains? -- Because I feel progressing in a career ladder requires understanding of intrinsics of business, I have peers who started at same time with me together in career and continued in the same domain are currently in Architects / Lead developer roles.

Any inputs from experienced people will be helpful. Thanks in advance.

[-]

ProbablyNotPoisonous@reddit

I have over 10 years' "experience," but only one of those years was on a team with any kind of functional dev practices. The others were all bug hunting (which I love, don't get me wrong) and ongoing development on old codebases whose architecture I can most charitably describe as... "organic" :P

I'm not sure what kind of jobs I should be looking for. I don't think I'm ready for a senior role, but I also feel like if I apply for a junior role, my resume looks good enough on paper to make me seem overqualified :/

Also... I don't know all the newest platforms, etc.; but that's because I learn best by doing. My fundamentals are rock-solid, and I've found that picking up new technologies and frameworks is best done as needed/as I go, but would a potential employer see it that way? "No, I haven't worked with any of your stack; but I'm a fast learner" sounds an awful lot like "trust me, bro."

Basically I feel like I'm still a baby developer, but no longer young enough for that to be cute :P

[-]

F0tNMC@reddit

I wouldn't worry too much about having experience with specific stacks. There is so much variability in technology and in how organizations use them that few things are directly transferable. That said, having a small hobby size stack that you run GitHub -> build -> AWS might be good to play around with if you have the bandwidth. But only do it if you find it educational and fun. This profession can be draining enough without adding more drains on your mental energy.

I think that being curious about the stuff you encounter at work is the best way to learn things. Try and go a step further than finding the solution, by learning the why's of the solution, and alternatives you know about but reject.

With 10 years of experience, I would definitely expect you to be well beyond junior, if not in breadth of experience, then in attitude, aptitude, and ability to adapt to challenges.

[-]

Flashy-Whereas-3234@reddit

Jobs are weird and varied, just like the companies and people who run them. You can't tell from a job ad if a role is going to be what you think it is, just like they can't tell if you are what you say you are, and how that translates to skills

If you're in a comfortable place right now, you can both be interviewed and interview the company/role

Don't fret over your resume meeting or exceeding requirements, you can just shotgun that thing at companies and see if they bite. You're not inconveniencing anyone, hiring inboxes are mental anyway.

If you actually like the look of a role, weave so keywords into your resume that are in their JD, and do a custom cover letter pointed towards them. There's so much AI in hiring now I wouldn't spend more than 10 minutes on this, but it helps get you through the gates.

And then just interview. Maybe you're perfect for a role but you'll be super anxious and weird in the room and you just need to chill out. You might find you're well above others in your space, and have senior opinions even though you've got crazy imposter syndrome.

There's no negative outcome here besides wasting your time.