Ask Experienced Devs Weekly Thread: A weekly thread for inexperienced developers to ask experienced ones
Posted by AutoModerator@reddit | ExperiencedDevs | View on Reddit | 74 comments
A thread for Developers and IT folks with less experience to ask more experienced souls questions about the industry.
Please keep top level comments limited to Inexperienced Devs. Most rules do not apply, but keep it civil. Being a jerk will not be tolerated.
Inexperienced Devs should refrain from answering other Inexperienced Devs' questions.
qualitywolf@reddit
I cofounded a startup many years ago but left after awhile and released my unvested shares -- but I still own 4% of the company.
The company has survived, stayed very small (<5 people), and pivoted into something that is starting to build some traction and making real money. They just raised an early round with a top silicon valley VC as the lead investor.
Now they want me back but and have given me a founding engineer offer that isn't particularly generous but seems about the same as other similar stage companies in my area. However, there is a condition that I'd need to revest half of my already vested equity. I will be receiving a new equity grant but it's a fraction compared to what I already own.
I'm living a comfortable life a big tech company making 400k+ in TC. What would you do?
0x53r3n17y@reddit
I'd stay put.
You own 4% of a company, and you don't have to actively involve yourself. Meanwhile, your current income and all the perks your employer offer you puts you well beyond the 97% percentile of household incomes in the U.S. And you're happy and comfortable where you are, at a place with options to grow your career path.
And you think about swapping all that for a start up where you have to (a) give up your stake in the start-up (b) accept an offer that's sub-par (c) receive a title of "founding engineer" which doesn't say a whole lot about what you actually get to do, or the hard decision making power you will hold (d) land within a small start-up which, likely, isn't recognizable anymore from what you left behind, offering questionable prospects for future career growth.
burnerprogramer42069@reddit
How bad is it to have 10 YOE and not be at a senior level?
I just received my end of the year eval and was found lacking. I fully expect to be put on pip and be looking for a job in the new year.
I started looking around and seeing most job postings for my yoe are for senior positions. But I'd never consider myself senior. Does it look bad or weird for me to apply to mid level positions requiring less yoe
hiddenhare@reddit
A question for engineers working in orgs where unresolved code review conversations prevent the PR from merging:
When the reviewer and the author continue to disagree, how does the tie get broken to unblock the PR? Does your org have a written rule like "author wins", or "most senior wins", or "bring in a third engineer to decide"?
qualitywolf@reddit
I think if discussion has failed, we'd bring a third opinion in to weigh on it.
Also depends on the issue. Is it some sort of code nit? Not worth arguing over. Is it a big architectural decision? Let's maybe back up, why is the discussion happening at the PR stage and not earlier in a design stage?
2_bit_tango@reddit
We don’t really have a rule. For context, I’m a senior on a team <20. In my team, there’s one dev who has a “my way or the highway way” attitude. If it’s him disagreeing I tell the newbies that they can ignore him. A lot of his arguments are “better” ways to do things but they are harder to read, or just dumb picky stuff that it’s a hill he’s going to die on. I typically disagree every time and say go with readable, and if it’s nit picky formatting you can fix it if you have other things to fix. Otherwise, merge. Ain’t nobody got time for that. If it’s an actual problem, then we usually move the conversation to slack and pull in the team to decide, or if it’s a big problem do a meeting. Of course, ideally you’d have most of this hammered out before the PR stage, but newbies going to newbie (not always newbies but most of the time). It happens. Otherwise the deciding vote is usually the one most familiar with the thing, be that the author or not. It mostly just comes down to judgement, with newbies asking seniors if they don’t know.
These-Loquat1010@reddit
How can you tell when you've progressed from a junior to a mid-level engineer? Specifically, what technical and hard skills do you need in order to become mid-level? and where can you learn them independently? I am a junior engineer who wants to advance quickly in my career.
Prime_Outlook@reddit
I’m a full stack developer w/ 3 years of experience in consulting at a large company. I switched jobs about 1.5 years into my first job as the work started to slow down. Joined a small company and had my first performance review after 7 months.
During my performance review, my boss shared with me that he sees me more as a mid-level developer because even though I may need my estimates padded with a few extra hours compared to a senior dev, I still was able to complete my tasks without much hand holding and could communicate with leadership effectively. Also, my boss described me as tenacious.
So just sharing my experience (it’s not everyones), but being mid-level means that you’ve become adept at your companies tech stack, have a grasp on the code base (ask meaningful questions when you don’t), can keep your composure when things get hard, and can communicate with customers directly.
These 4 things are what you should strive for (to some degree, at least in the consulting space). I’m guessing that when I start looking for new roles in the next 3 months, that I’ll have to sell to my interviewers that I have skills for understanding new code bases, have the skills to contribute to their tech stack, and I understand what’s needed to happen before my code reaches production.
Hope my response provided some useful info!
casualPlayerThink@reddit
In short: "quickly"? Not really possible.
Longer:
It's more like mindset, experience and wisdom. You can improve your skills, but most of the time it is based on your skills, knowledge, intelligence, luck, opportunity, common sense and connections.
I know, many freshly grad with 1-2 years of exp think, they are already seniors, and they are pretty pissed when someone tell them, lets talk about this like in 6-8 years later.
Of course, purely years in the field does not make you (good) senior, I know a bunch of engineer w/ 15+ years of experience but on a level of a junior.
IT and engineering is a never ending learning path. There is no day, when you can not learn something new, can not sharpen your skills or improve something in yourself.
What you can and should do: improve yourself, start to think about the system design, the bigger picture and the business side of decisions, tasks or in general your workplace business models. Open your mind and step out sometime of your comfort zone. You might shape your knowledge base and your personality too. Try to step up sometime, even if you fear of failure. Do it, fail it, learn from it, get up, do it again. Rince and repeat.
ProgrammingQuestio@reddit
How to learn about improving a frustratingly fickle CI/CD process?
We use Jenkins to run stack tests/mod tests, among other things. Recently I've been using it a lot and it's become apparent how fickle it is. A good, no-issues run takes a while to complete. I figure this is expected. But the problem is how it feels like 1/3 of the time, the initial step fails to fetch the repo. Or some piece of hardware is offline/fails to connect. There's some issue that makes it not work in the first place, or just take wayyyy longer than other times. There's just a lot of issues that make the feedback loop incredibly long and painful, when the best case scenario already takes a chunk of time.
It's one of those situations where I'm asking myself, "Surely there's a way to make this work better/be more consistent, right? But if that was the case, wouldn't these more experienced people around me have already done it?" It's just a huge time sink and I have a hard time thinking I could do anything about it, but man is it frustrating.
c0deButcher@reddit
Which is a better way to quickly grow? Switching or promotions
casualPlayerThink@reddit
Normally, I would say, by learning, but you are interested in financial grow, so usually Switching (except in fintech/bank and some special areas and levels)
MagicianSuspicious@reddit
What are you seeking to grow? Compensation or skills?
Compensation is probably maximized by changing jobs.
My experience suggests that sticking around and seeing the effects of your design choices over time, is a big part of improving.
roger_ducky@reddit
I tend to find sticking around means you understand the business logic and can play office politics much better, but compensation increases the fastest by switching every 2-5 years, at least until you hit senior level. After that, it kinda depends on how much your employer is willing to pay.
dbxp@reddit
Promote and then switch is the classic move. The promotion pushes out a linkedin update to all the recruiters and now your eligible for jobs at that new level.
pachumelajapi@reddit
Unfortunately… yeah
Optimus_Primeme@reddit
Switching 100%. I wish it was promotions, but sadly it just doesn’t compare
braino42@reddit
It depends on you and your current role. Does your current role allow you to act as the next role? If not, you will need to switch to a job that will.
mudigone@reddit
How to find remote jobs? What's your goto approach?
casualPlayerThink@reddit
HN, good filters on job portals, remoteok, and digital nomads might help you.
Also, tailor your resume, even go to the r/EngineeringResumes subreddit and ask for reviews and help
sneakpeekbot@reddit
Here's a sneak peek of /r/EngineeringResumes using the top posts of the year!
#1: [0 YOE] The revised resume that got me a job at SpaceX after ~ 400 applications | 80 comments
#2: [15 YoE] Hiring manager's perspective after recent review of 100s of resumes for entry level roles in software.
#3: [Student] Should i put this on my resume? Built a Minecraft calculator from scratch. no tutorials, just CE/CS studies | 57 comments
^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^Contact ^^| ^^Info ^^| ^^Opt-out ^^| ^^GitHub
Optimus_Primeme@reddit
Hacker News monthly “Who’s Hiring” post. news.ycombinator.com
MinimumArmadillo2394@reddit
In my 3 months of experience with that forum post, Ive gotten 0 responses despite a dozen or 2 emails/applications.
Sometimes they post again and again hoping to find someone but they keep rejecting people.
The forum post is about as useful as linkedin.
TheLittleBlackDuck@reddit
Job website, e.g. cwjobs or indeed. Filter by location: remote
kareesi@reddit
Looking for some advice on how to advocate for my promotion.
At my current role, I intentionally accepted a down level from SDE2 to SDE1 for a significant pay raise. I’ve been in the role about ~9 months, and in that time, I’ve substantially grown my scope of responsibility, delivered on several impactful projects, mentored a new grad, am being asked to design and lead features, and scope work for other SDE1’s. Looking around at the other SDE2’s on my team, I’m at least performing at their level.
I feel very strongly that I should push for a promotion to SDE2 this cycle (in January). I put together a page documenting my work and showing how it aligns with the SDE2 role expectations, and discussed it with my manager, who has been at the company for about 4 months. My manager said he wanted to push for getting me a 4 or 5 (out of 5) this cycle, so that next cycle the promotion was a sure thing. He noted a few (small) gaps in evidence for a packet, which I have since taken steps to rectify.
I recognize I’m in a bit of a tough spot here because ultimately my manager is the one who needs to advocate for my promotion.
I’ve got a 1:1 with my skip level tomorrow and I plan to advocate for pushing for a promotion this coming cycle. I don’t want to throw my current manager under the bus, and I think framing it as “revisiting the evidence needed for a promotion packet because I believe we have sufficient evidence” is how I’d like to approach it. Can anyone give me some feedback on how to tackle this/if my approach and framing sounds reasonable?
DeterminedQuokka@reddit
Do you have the actual requirements for promotion? Was the talk with the manager the first time you brought it up? A lot of companies have sort of hidden requirements for promotion and that might be what your manager is talking about.
The way I would frame it with the skip level is a conversation about what it would take to get a promotion with someone with more time at the company than your manager. Say you want to really understand the process.
Honestly they are super unlikely to override your manager and most promotion processes are unanimous from my experience. So what you want to get from this is if the hole your manager sees is a real hole or not. And it might be.
I definitely worked somewhere where this pattern happened a lot because people didn’t know the policy and when they asked they weren’t meeting the promotion policy which can be different than being good at your current job (everywhere I’ve worked it’s actually being okay at the job you want to be promoted to).
It also can be very weird at some companies if they are the wrong gaps. Like people get super obsessed with some gaps. Like I got a promotion rejection that said I was fully meeting all expectations of the next level but there wasn’t enough evidence that I would “disagree and commit” enough. Which my manager and I determined to mean I needed to explicitly say the words “I disagree and commit”. On documents instead of “okay that’s fine” which was apparently passive aggressive…
Normally I would say your manager knows something about the process, but given their tenure the problem might actually be they don’t and such aren’t sure they can succeed at it yet. Is your previous manager still around? If they are I would talk to them and see what they think.
Side note some companies have a ridiculous minimum time in position rule. Although I don’t know why the manager wouldn’t have just said that if you did.
kareesi@reddit
Yeah, I have the actual requirements and I’ve also spoken to others who recently went through the SDE1>SDE2 promotion process here to get a better sense for it, and multiple people have advised me to push for it. We do have a soft cutoff for the minimum time in position/company, and I’d meet it at the time when we’d be putting me up for promotion.
Thanks for the tip on using the skip level conversation to see if they see the same holes my manager is seeing. My current skip level is actually my previous manager who filled out my performance review last cycle. I intentionally addressed the areas for growth he mentioned at that time, and it seems like revisiting that and making sure he has the same perception would be a valuable use of that time.
DeterminedQuokka@reddit
Also without mind reading. I think there is a world where your current manager might be worried putting you up and getting rejected makes you more likely to quit than delaying you. I don’t know if that’s true but you could be honest that if it doesn’t work out that’s okay and you know you can try again.
kareesi@reddit
That’s a great idea, thank you! I can say in all honesty I would not be crushed, I recognize that in corporate things don’t always pan out perfectly timing wise and it doesn’t necessarily say anything about my actual performance or abilities, I just want to get the ball rolling on this sooner rather than later. Sharing that I recognize and accept that risk and won’t be crushed if it doesn’t happen this cycle might help alleviate some of his concerns.
roger_ducky@reddit
Though also keep in mind that “1 quarter before annual review” is typically too late to advocate for a promotion. You typically need to be at least 2 quarters ahead before your manager could even start the process. Though, definitely ask. My specific place recently changed rules so junior 1 to junior 2 no longer needed special approvals. But it might not be the case where you are.
DeterminedQuokka@reddit
That’s actually awesome. If they are your previous manager they should have really good insight.
IWontBiteLol@reddit
Hey I'm a "senior" in a company.
It's 2 levels above college grad level.
Junior SE - SE - Senior SE - Principal.
Technically I have only 3yoe and I'm 24 years old. I got a bunch of quick promotions because my manager needed work done (both code munching and designing) and I was a reliable go to man. I've been with the same product and team throughout this time.
But I still get impostor syndrome every now and then. Most other seniors are 28+ in age and 7+ yoe.
I mean I can hold my ground in tech discussions and design sessions , but I feel like age is sorta becoming a hidden constraint here.
Meanwhile I vibe more with the junior engineers , but they don't treat me like a senior cus of my age 💀.
I'm losing on both fronts and I'm confused on what to do.
And don't let the title fool u , I really can hold my ground against these other seniors (could be because I know the product longer than them and I've worked on pretty much a new tech stack every 6 months , more breadth compared to depth)
0x53r3n17y@reddit
So, the tech industry is more then a couple of hundred of large, well-known companies. It's a vast and diverse field. You can find teams making software in niche markets you've likely never even heard of or considered. It also means that you will find all manner of organizations in which people write code.
With that diversity comes the fact that the "senior" title and actual seniority aren't necessarily aligned. People get the title "senior" for all kinds of reasons. In your case:
Plain and simple: you have the title, but you don't have the years.
A big part of seniority is maturity. Some things are only learned through the lens of time passed. You will look back at some experiences very differently having 3, 5, 10, 20 or even more years from now. It's the same as if you would now, at 24, look back at your own 18 year old self, and re-assess how you said things or how you behaved.
That's just not something you can rush.
You aren't "losing" anything. You've got a golden opportunity to learn a ton. And it all starts with acknowledging why you got that title in the first place. Sure, it feels good, and there's nothing you should feel guilty about. But your mission now is to grow into that title for as long as you are staying with your employer.
For one, the title "senior" isn't a free pass that will make people spontaneously listen to you. It doesn't work like that.
So, when you're sitting in with the other senior engineers: don't try to assert your position by budging into discussions, or trying to "hold your ground". It's not a them versus you kind of thing. Instead, be humble, learn to listen in and take note. You'll definitely are going to make mistakes because you lack perspective. Learn from those. You will gradually ascend into seniority if you give yourself time.
Same deal with the juniors. These are, age-wise, your peers. Of course they won't treat you like someone with more seniority. Again, you'll need to give this time. It also means listening to them and to be smart about which battles you're going to pick with them. You need to earn their trust and respect first, and that means helping them out but also letting them make their own mistakes nad helping them learn from those.
MagicianSuspicious@reddit
Everything here \^.
Also: as someone on the hiring end, I'd much rather hire someone who has some amount of self-doubt/imposter syndrome, than the "Senior Dev" who thinks they've learned all there is to know about software development in the five years they've been doing it (which is surprisingly common).
Tomatoies@reddit
We need more people like you. Too many interviewers expect non-stop confidence from their candidates and see signs of self-doubt nervousness as undesirable.
roger_ducky@reddit
It’s not what he said exactly. I’m a hiring person too. I want people to tell me honestly the limits of their knowledge and not “hallucinate” confidently like a AI when they don’t know the answer.
I sometimes ask questions I know you probably don’t know. Or an open ended question that will test how much of the whole thing you know. It’s okay to admit you don’t know the answer for a specific thing. As long as it’s not literally everything I asked you about. “What’s your name again?” Is not one I expect you to not know, for example.
kareesi@reddit
Another question — how can I best market “glue” work, as a junior-mid level engineer, in particular with management who doesn’t explicitly value it?
For example: I took ownership of a component by co-leading a feature to improve on it. During that process, I discovered that the component had several old versions we maintained that made it difficult to read the code and iterate on it. Those older versions were still in use by some obscure tools and a small subset of customers. By asking around (product, our principal engineer, some peers) I discovered that those tools were obsolete and was able to gradually deprecate the unused tools and get buy in to migrate off the old versions.
As a result I consolidated the component versions we maintained from 4 to 1 and was able to deprecate a bunch of tech debt that made it much easier to operate in that area of the codebase, and was able to refactor the code to set up a better foundation to expand and build on it in the future.
I’m exceptionally proud of this work, but I worry that it’s unlikely to be rewarded unless I can figure out how to market it well. My company doesn’t really value this kind of “glue” work in junior and mid level engineers, because at this level we are largely evaluated on PR counts and “craft excellence” which equates to code review counts and on call improvements for jr and mid lvl engineers.
I can obviously market the tangible technical contributions of the tech debt removal and system architecture piece, but do I just need to accept that I might not get credit for this kind of work until either a) I am more senior or b) I have a manager who recognizes the value of this kind of work? Any advice?
roger_ducky@reddit
Stress the amount of time saved in both development time and the amount of cross-team buy-in you had to go through to get it across the line. Your manager will appreciate the amount of legwork you did, if nothing else. Hopefully he’s also technical enough to understand how what you did will increase velocity dramatically in the future.
Frenzeski@reddit
There’s plenty of literature on this
https://www.noidea.dog/glue
https://nathanielmorihara.medium.com/beware-of-glue-work-5812119a3b02
kareesi@reddit
Thanks for the articles. I am aware of the concept of glue work and the risk of taking on too much of it as a junior engineer, and have taken steps in my overall career to balance glue/non glue work. Doing some of it is important for me to learn and grow into a more senior role though, and it’s work I find fulfilling, which is why I asked how to sell/market the impact of this work.
Frenzeski@reddit
Sorry for telling your grandmother how to suck eggs
Charity Majors also wrote some thought provoking blogs on this topic
https://charity.wtf/2021/03/07/know-your-one-job-and-do-it-first/
https://charity.wtf/2021/03/09/know-your-one-job-continued/
They reflect IMO how some companies devalue glue work and this can lead to being marginalised. I like that she also points out that you should know what your job is and do what’s expected of you even if glue work is higher leverage. This is especially true of juniors, it’s nuanced because you may feel there’s a lot of value in this work but as a junior/mid your primary focus should be smaller scoped. Without a good foundation of technical and product knowledge you’re going to struggle in your career growth, if not now then later. Wider scoped work is incredibly valuable as you get to Staff+ levels, and so the fact you’re already thinking and doing it will set you up for success.
But my advice (based on the limited information i have if the situation) is instead of advocating for being recognised for it you ask for permission instead, pitch it to your manager or tech lead and listen to their feedback. Getting buy in is itself a skill necessary to do glue work successfully.
kareesi@reddit
My understanding of what you're saying is that earlier in career, if you broaden your scope too much too soon, you can potentially miss out on building technical knowledge and depth that will serve you later in your career/be necessary for career growth? And that it can be a distraction to take on the glue work if the technical work that the glue work is in service of isn't work that is part of your "one job" like the article describes?
So the purpose of pitching it to manager/TL/PE/the powers that be would be to:
1) learn how to generate buy in and successfully pitch work you feel is important and get it prioritized and
2) leverage the broader context that the TL/mgr/PE have to discover whether the work is important in the bigger picture, which is perspective I might not have as a junior/mid level?
Frenzeski@reddit
Exactly
kareesi@reddit
thank you for taking out the time to write out that thoughtful answer! I learned a lot from the replies to this post.
cosmopoof@reddit
The key here lies in the question if the company is benefiting from your work or not. How much effort still went into maintaining the old versions? How many delays were caused by it? In the other direction, is there any tangible benefit that goes beyond "much easier to operate" in the new codebase? This is only relevant if the component is really touched regularly. As the tools had been used by customers, was there dissatisfaction by them about it? Did you solve real customer problems? If so, did you think about upselling opportunities and clear that with key account?
So, really look at the hard facts from an economic point of view. How did you earn/save the company money or reduce actual busines risk or enabled a really needed capability. If you clearly did, that's your business case that you can use to show the value of your work.
If you can't easily answer this, it may well be that you fell into a trap here of mainly creating effort in many places for little gain and there would have been much better options available (opportunity cost).
If you think about your career progression, making better business decisions as an engineer is a huge benefit, as this tends to leverage your limited hours of work.
ligirl@reddit
This was The One Thing I had to learn to progress from mid-level to senior.
kareesi@reddit
Thanks a ton for this — these are some really insightful questions to chew on for both this situation and to ask myself to help prioritize future work as well.
Suepahfly@reddit
Write a “brag document”. Share it with your manager, ask for feedback on it, keep it up to date and use it next performance review
pierre_lev@reddit
Just be vocal about it when there's a meeting about your performance.
Technical debt and readibility is very important to be always improved and resolved, but its often oberlook because of the economic measures and profitability.
Software is like a living organism, it needs good care and some trimming sometimes.
No_Flounder_1155@reddit
The best way to sell to management is to understand how to put a $ figure. The result of this work is I assume time and therefore cost saving. How would you measure that?
Devs will understand and entertain complexity. Management needs to understand the saving in terms of $. If it did nothing in terms of $ saving, what was the point?
alreth@reddit
I feel bad writing this since I'm not perfect myself, and I'm probably just being an asshole, but how do you deal with fellow software engineers who write sloppy code? Like, they'll create variables that require non-trivial calculations that aren't even used, have haphazard indentation, leave in tons of debug statements, misspell things, and generally use inefficient and redundant logic in their code.
To note, we do do pull requests, and I do suggest fixes, but having to point all of these things out takes up a lot of my time. I wouldn't mind pointing things out from time to time, but they don't seem to improve their code, so I have to keep cleaning up after them as if I'm their parent. What do I do? Do I just deal with it? Am I missing something obvious to do? Am I just filled with ego?
roger_ducky@reddit
If you can, try getting team buy-in on a coding style and get a linter they can run locally. Then the PR build can use the same linter to block merges based on if the linter would have changed a file.
Formatting would always be consistent then. What we’d be left with are just weird variable names, which should be addressed in the PR.
alreth@reddit
I've heard of linters here and there... I should probably learn how to use those. I'll look into that, thanks.
roger_ducky@reddit
They are typically command line utilities that can read and reformat syntactically valid programs files for a specific language.
Most of them support a “check” mode and a “reformat” mode. This will reduce amount of arguments once a format is initially agreed on.
AI_is_the_rake@reddit
Don’t clean up after them. Write comments on the pull requests. Consistency and low expectations are key. Eventually you’ll look up and notice change if you’re consistent.
alreth@reddit
That's reassuring. Thank you.
ivan0x32@reddit
Kind of strange question, but what field can you switch to from IT really? Read in the other thread that other fields are not experiencing this bullshit with hiring, realistically what (white collar) fields would be a good fit for someone with a typical skillset of a software engineer/architect?
I have a job right now and I'm in Europe also, but you never know what the fuck is going to happen to the field.
roger_ducky@reddit
Have you considered a software job in another industry? Sometimes the demand for developers increases in one while decreasing in other ones. That’d be the easiest thing to do.
Aside from that, things like process management and any “continuous improvement” stuff should directly translate from your software experience. Profiling processes, A/B testing, and root cause analysis should be second nature. You might need to get “officially certified” but it shouldn’t be too difficult.
pachumelajapi@reddit
Your analytical skills should work on anything business related. Decisions are something most people struggle with, we do them every day. Any sort of management of resources would work with our skillset. We know about the importance of gathering data and creating processes (algorithms) to predict different outcomes
Kool-Kat-704@reddit
Any advice on looking for a new job within the same company? I really like the company, just not enjoying the stack I've been working on and I feel I could progress more in my career if I moved towards something I find more interesting. Just looking for advice on how to appropriately do that without upsetting my current manager/team for leaving.
roger_ducky@reddit
This totally depends on manager.
Is the manager typically supportive, or a super vindictive person? If vindictive, forget it. Leave company and re-interview. That’ll go over better with current manager. I’ll tell you why in a bit.
But first, figure out what rules, if any, the company have for team transfers. Make sure you actually can do it.
Afterwards, go interview with other teams.
Finally, once something is lined up: Inform your manager of the intent to transfer. If they’re not the vindictive type, they’ll give you your blessing and let you go on their way, once you finished the things you needed to finish for the team.
If they are, expect them to immediately try to manage you out using every trick in the book, blocking your attempt to transfer, while also attempting to mark you as a permanent “do not hire” in HR records. How dare you not love working for them?!
Kool-Kat-704@reddit
This was very helpful, thank you. I think my manager is more on the supportive side, but I'll spend some time figuring that out before making the move.
magiciancsgo@reddit
Hey, I'm an intern at a F100 company, I have a quick question on unit tests. I've always written them with the understanding that they are there so if someone changes code and it inadvertently affects the code that was unit tested, we can have confidence that that code is still working properly.
However, at my company it seems like many people treat unit testing as more of a real-time QA process. My thought process is that we don't really need "QA" tests being ran every time in the pipeline. If it helps you write better code, awesome, but it's probably better to delete it before pushing.
Is there an objective best practice, and if not, what do you recommend?
roger_ducky@reddit
Sometimes you start with a small test for a single unit of code. Then you realize the unit wasn’t so simple after all, so you refactor it into multiple modules.
How do you ensure the original unit worked as originally intended? You run the original unit tests. Now testing a bunch of “units” together.
If you then don’t have time to move the tests around, you get your “QA” tests.
Other thing you might wanna check out is the Chicago/Detroit school of TDD vs the London school of TDD. Your team might be leaning the American way more in this case.
Frenzeski@reddit
Making sure i understand the question, you’re suggesting deleting unit tests before pushing code. but how will the next person to touch that code know if they’ve broken it?
magiciancsgo@reddit
Oh, I'm only saying to delete unit tests for the "QA" style unit testing that I was talking about. Where the benefit is really that it's helping you write better code, not it's a good unit test.
Frenzeski@reddit
I don’t really understand what type of tests you’re referring to
pachumelajapi@reddit
I think that by “QA” style you mean integration and sorta end to end. There are tools that do that, unit tests shine for testing small pieces of code. Focus on the important parts of the code, no need to test everything. You can develop a small test you can use as a smoke test to verify important functionality is there. You can use postman collections or cypress for that.
ashultz@reddit
You're getting hung up on the word unit and trying to throw away something useful.
Some tests are very small and test a little thing.
Some tests are larger and test a more complete flow.
Both types of tests prevent (some) breakages in the code they are testing if they are well made. As the system has small and large behaviors, so the tests must test both small and large behaviors.
Some people are pedantic about what a unit test is vs an integration test vs an end to end test. That's just nomenclature wankery, tests are tests.
negswell@reddit
Do I need an mba to climb the corporate ladder , I feel software engineering interviews are getting harder year by year and are kind of unpredictable
roger_ducky@reddit
Past a certain point, it’d help. But mostly because of what they teach you more in business school. Specifically about process management and continuous improvement. Once you know that part, then why we do the ceremonies in agile makes way more sense.
Accounting related stuff is also helpful when you need to guesstimate budgets.
Asleep-Outcome-5931@reddit
For my next project, I want to build a cross-platform app with React. I'm looking to avoid having 2 different codebases if possible.
Since React docs suggest using Next.js and React Native docs recommend Expo, I wanted to use Next.js with Expo. But Expo doesn't officially support Next.js' app router as far as I'm aware, which is a dealbreaker unfortunately.
So instead, I'm now looking at Capacitor. Others seem to have good experiences with it, but it doesn't support SSR in Next.js. Do you find this a significant limitation? Anything else I should be aware of - or if you've used a different stack, do you mind sharing your experience?
AI_is_the_rake@reddit
Tough questions for sure. Capacitor would be your native app not server side rendering. Webpack 5’s module federation could be worth exploring.
PhDinOmniscience@reddit
Roast my system design: https://excalidraw.com/#json=C0NRFKFOUtTCnZvujMc-s,3ARbuJxpR3bJ6PTj8zllcA
I've been practicing system designs for a mid-level role. Would really appreciate it if experienced devs can roast it and tell me places that don't make sense. 😃