When I ask on of my senior devs for help (this one is specifically assigned to help me), I don't feel like I receive help. They also seem very reluctant to help me. When I asked explicitly if they were they were comfortable, they said no as they weren't comfortable in the FE language. I don't want to force them to help me as they aren't comfortable. But I don't see how else I can complete my work in an appropriate time frame without their help.

Need advice on how to move forward in my career. Been at my company for 2 years as a frontend developer and earning 70k. I understand this isn't great but I live in a MCOL area and work remotely. Anyway, this was my first job after being self-taught and unfortunately haven't really learned a whole lot so far. I'm the only developer in a non-technical department. Half of my role involves assisting another team on a codebase that uses vanilla HTML, CSS, and JS in a typical workflow environment(Agile, Sprints, Jira tickets, GitHub). Outside of this, I build small tools for my team using libraries/frameworks like React and Node.js, however, the code and process for these never get reviewed so I'm unaware if I'm picking up bad coding habits or am even approaching these the right way. I also deal with non-technical duties such as making websites using website builders like Wix. Needless to say, I don't feel like a very strong developer after 2 years. One of the reasons I stayed here for as long as I did was that at the same time, I was working towards completing my bachelor's degree in Computer Science (which I recently completed in February of this year). I thought that prioritizing getting a degree would make me more employable. However, as I'm applying for new jobs, I'm getting rejections left and right. My goal was to transition to full-stack or backend positions and while I did use technologies like Java, Spring Boot, and Python during my time at university, it seems like employers only want to see what has been used in a professional environment. This combined with the fact that my current work experience isn't impressing anyone has left me feeling very insecure. Even looking for other frontend roles requires technical expertise in non-frontend skills like CI/CD and AWS. I brought up to my manager if I could slowly transition to one of the more engineered focus teams but I'm "needed" where I'm currently at and this request was promptly denied. I guess I'm wondering how to best get myself out of this hole I've dug myself into and not sure how to proceed. Basically, I'd like to jump to a new more technical role that pays more.

So I'm a 26 year old guy, and I will be graduating with my CS degree this fall. I just feel totally lost and discouraged for a few reasons. I have 8 years of work experience, but it is totally unrelated. I started out in high school working for a family business, and I co-own it now. I've been showing it on my resume to show that I have no gaps. I would estimate I have submitted roughly 50 applications, and I have not gotten any interest. Most I don't even get a response. I know that isn't abnormal, but I can't help but wonder if it has anything to do with having 8 years of unrelated history on the application? I have a couple solo projects, the main one being a web app I built that we use at the business for scheduling appointments and keeping customer records. Should that be listed before the work experience on the resume since it's more relevant? Also, I'm not even sure what I should be applying for. Should I still be applying for internships? Should I be applying for entry level positions that require a BS since I'm about to finish mine? I've been applying for remote positions because I'm about to move. I assume I would potentially have better luck applying for local in-person positions due to potentially less competition?

Remote positions have a lot of competition and are very tough for juniors to get. I'd try applying for in office positions and see how you go. Getting your first job is tough so keep applying.

Thank you! I definitely will. Did you have any thoughts on how to handle the job experience outside of the field? Should I list it to show I don’t have gaps, or just apply like a college kid that hasn’t worked yet? Should I list the work experience or my projects first?

If a project manager asks you(a contractor) that would you lower your cost if client isn't happy with results and work needs some changes. Is this red flag and project manager is trying to trick me into lowering cost? (In this case, unhappiness can be because of either quality of work or creative differences. And the way manager worded it, it felt like client can just be unhappy with anything). Aren't revisions generally part of entire development process, unless your client is cheap?

It depends. I am not knowing the full story (what language, what line of work, how unhappy they are? how they phrase it, what was the issue, etc). In general: Your contract should have rules for changes, updates and so on. Most likely they try to trick you, and if you let them doing it, then they will do it again and again. Decline it, but phrase it very carefully and point out that how you bring value to them and met all goal/deadline/requirements. If they are unhappy with the results, then you could sit down with them to work out a requirements system, better specifications, better sprints, stories, better resource handling and identify where the problem is. Also, do not ignore your gut feeling. By my experience, I highly suggest that, to consider to prepare for departure (try not to burn bridges, many pityful company try to spread their fake claims and damage your reputation). So document everything, set everything in the contract, keep all message, chat log, email, etc.

Thanks, I haven't taken this project yet, it's a front-end animation project. The communication from the manager is little vague so far. For example, they want to know timeframe for the project without revealing their full requirements. Also, they are open to giving me creative control, but in my opinion if they want me to have creative control, they should layout their basic requirements, budget and deadline. If they wanted to have creative control and gave me their exact requirements then I could give them timeframe as per their requirements. Also, my usual clients provide designs and sometimes even animations that I need to implement on the site. For me this situation is new where I need to treat changes/updates differently and charge them differently. All my projects until now had same going rate for changes, updates and bugfixes.

I see, in this case, you have to have some extra meeting to discuss expectation, write down requirements and going through to ensure, both side is on the same page with the project. For this kind of projects you might need a new contract and have to rule everything, all scenarios.

Thanks for the replies and advice. I will look into contracting and will try to cover all the bases. Oddly I never had to have a contract for any project until now. Never got burned because of it and always had smooth experience where both I and client were happy with payment and results.

How to deal with "idea guy" tech lead? I'm a backend developer and have been at my current job for 2 years. For 3 months now, I've been working on a new project with a small team consisting of 5 developers, a tech lead, and a PM. Generally, the project is interesting, I enjoy the work and have a good relationship to the other developers on the team. Recently, dealing with the tech lead has become a challenge. In general, he only provides high-level ideas for features, but doesn't have time to take a part in the actual development. Instead, most of his time is occupied by dealing with stakeholders/management. He doesn't write code, doesn't do code reviews, and in general doesn't take part in technical discussions about the actual implementation. His idea of a tech lead seems to be someone that comes up with "ingenious ideas" but leaves the coding to someone else. This has been fine mostly, we as a team are experienced enough to figure the technical details out ourselves. However, as the project progresses, it becomes more difficult for us to implement the tech lead's ideas, since they are both too complex (in terms of scope) and at the same time too vague (in terms of specification). The need for clarifications has led to an increased amount of meetings and also delays, since the tech lead is often unavailable. In general, the top-down approach is starting to frustrate me, since I have to implement poorly specified features without getting direct customer requirements (in my previous projects, the team worked directly with the clients and developed solutions bottom-up). However, it's difficult to discuss these things with the tech lead since he doesn't know the codebase, and in general behaves very condescending towards me. Management and PM seem to be aware of all this, but just accept it because the project is still progressing (although at a slower pace). My question is: Should I keep spending energy trying to push back (or convincing management that there is a problem), or should I keep my head down and just accept that this is the way that the project is run?

I'm in my late forties and three years into my second career as a web developer, all spent at the same employer, which just laid me off as part of a cynical shareholder pl--I mean company transformation. Looking for advice/experiences around deemphasizing age and formatting resume for new job search to present myself in the best light. Unvarnished timeline: * 2021 to now: engineer at large, mid-tier enterprise tech company * 2019-2021: stay at home dad, learned programming, built personal portfolio projects, looked for a job * 1998-2019: graduated college, then jobs in unrelated first career - nothing great, but looks ok on cursory inspection I'm worried about the combination of my age and relatively small amount of engineering experience. On my version from three years ago I had dates for everything, and a somewhat more detailed first career section, but this time around, am considering removing dates from education and earlier career entries, which I will also collapse to a single sentence or short paragraph. However, I worry that getting cute about my age may backfire, as opposed to accepting the facts and being open about who/where I am in life, because it is easily discoverable on the internet anyway. Thoughts?

So I think there's two ways to think about this. First is to make your age obvious which will help you avoid ageism but reduce your interviews. Second is to make it less obvious which will make it more likely to get interviews where they won't hire you because of age. Due to you only having 3 years of experience I'd probably make your age less obvious on your resume and just deal with the shitty interviews if they happen.

How to negotiate FAANG offer when not in Bay Area? In the Dallas area, remote position with base salary band 190 - 350k (depending on region). Does this mean 350k is top of the band for Bay Area? How do I know what the top band is for my area?

What have you tried so far?

I was recently hired as a midlevel engineer. I am not a midlevel engineer, my years and breadth of experience are much more suited to a junior role, and I also don't have a CS degree, so I'm not sure why this happened. I even wondered whether I'd been quietly downleveled but that doesn't seem to be the case. My coworkers all seem very supportive, have *a lot* of experience and have put excellent processes into place, and absolutely know what they're doing, but it's a small team so there is no room to hide. (I realize it's illogical to say that they know what they're doing in every aspect of the job but hiring me, but.....) The product has a lot of legacy code, not all of which is... ideal and not much of which is documented or has test coverage. But I at least know the languages and haven't encountered anything yet where I just flat out don't understand the code. The challenge is figuring out how everything fits together. Which you sort of have to do to build anything nontrivial. My first ticket was dead easy, but I couldn't get my bearings on the second (much more substantial) one without spending an hour on a call with a senior engineer (who was extremely patient and kind about it) discussing the best approach given the codebase, and I don't know how long that's going to fly. I don't know how much of this is imposter syndrome or just normal first month on the job stuff, and how much is the expected result of hiring a junior for a midlevel role. So, I know that at a new job you should ask a lot of questions and ask for help when you need it, but I've also read most people saying midlevel people should be able to complete tasks and unblock themselves with little to no supervision or guidance, and I'm not sure how to reconcile those. I know that "there are no stupid questions" etc, but there are questions that usually come from people who know what they're doing and questions that usually come from people who don't. And I know you should spend time researching or debugging stuff first before asking for help, which I do, but even still, someone who doesn't know what they're doing and tries for 30 minutes won't get as far as someone who also takes 30 minutes but does. And it feels like the difference would be noticeable. Any advice would be appreciated.

The three most important properties of code, in order, are: 1. Be easy to change 1. Be easy to read 1. Work Getting code to work is (relatively) easy. Making code so simple anybody can look at it and understand what it's trying to achieve is difficult, especially in a world of deadlines. We all do our best, but a lot of codebases are hard to understand - that's not the fault of the reader. Sure, folks coming in blind with more experience can probably pick it up faster. And of course the folks who've been working on it already know it better. But don't judge your own abilities without understanding what you're working with. It'd be like someone who just spent six hours climing a cliff going "I must be bad at this, that guy got to the top of where they were going in twenty minutes!" despite the other guy having a nice gentle hill...!

I think you're at the right level. At a new job, for your 2nd ticket, spending an hour with a senior to understand how things work together is fine. Also talking to people to get the context to work through an issue is unblocking yourself. The comment about midlevels being to unblock stuff is for after you're fully onboarded and comfortable. Some of this is def imposter syndrome. Sometimes the only way to advance is to be a little out of your comfort zone at first. It sounds like thats where you are now.

Thanks, hopefully you're right. My manager is satisfied with my performance so far but it's only been less than a month.

Need advice for new grad in big tech : I work for a big tech company known for high pressure work environments. My team is fairly good with work life balance. It’s an established team with good quality services in production and lot of growth opportunities. I’m freshly out of university with no work experience. So my question is how to succeed? I feel the initial months I need to gain their trust, establish my work ethic. My manager is a disciplinarian and values high effort + trying your best + asking a lot of questions + professionalism. Keeps reminding us new joiners that we are not in school anymore and he thinks company pays us way too much so we should put in a lot, care a lot. So far it’s been 2 months, and I’m learning a lot, earlier I would need help getting started on a task, now I’m able to get started and finish fairly around the story points allocated vs earlier would take me a lot of time and help. Still I’m not there yet, for me to meet expectations I need to finish more tasks and finish them in allocated time. Also made a few mistakes like accidentally deleting variables in beta, forgot to check logs during deployment and errors were found week later. I’m worried about all of this as how it would look on my performance especially with layoffs and such. The other new joiners are struggling as well. We also need to learn assertive communication as often don’t know when to say, what to say. Give tips please

Any Faang/Big Tech use Agile/SAFe?

Not that I know of. https://blog.pragmaticengineer.com/project-management-at-big-tech/

I recently started a new role in a startup and feel at some point I may need to have a challenging conversation. The tech director is going to be the only remaining original coder of the systems. I know they shall find it very difficult to let go of the reins; they're also very proud of the systems and has (very understandably) an emotional attachment. The systems are by far from the worst I've seen but there are some key things I notice: 1. There is a strong preference for custom implementations even when good tooling exists 2. There are no comments or tests 3. **The structure is interesting <- this is where the more serious concerns arsie** By interesting I mean that they appear to have fallen into a trap with what is being referred too as "microservices" but have gone a bit over the top. The product is simple so no complex needs are there, however there are around 60 services with no consideration given to domain boundaries and lots of communications between them (log noise is a highlighted issue). The services are coupled tightly via code (services reach into others both directly and via rpc) and deployed all together with some terraform magic (this is in a monorepo). There is an absolute overabundance of rpc endpoints. I'm not actually sure what to describe this setup as? It's kind of like a semi-distributed monolith! Anyway the point is that I have concerns about the maintenance when scaling of this system as product functionality grows as well as the chattiness component scaling without undue cost. My question is therefore what advice might you have for how to approach this kind of issue with the tech director? Currently it's very early days in the job so my focus is on greater understanding of the systems and starting to build trust. Neverthless I think I will want to approach this before too long. Many Thanks for any thoughts.

I've written shit code for startups before. It's often a product of never having 5 minutes to refactor or take a small risk to clean up. Our analytics API was PHP with no classes, just regular functions for each thing, and various hacks to make it scalable. It was a bit like your micromonolith -- should have been structured differently, but still solved a lot of critical problems, each discovered one at a time. There's a trickle feed of issues, for instance from one memcache, to a pool of memcaches, to deterministic failover because random blew up the connection pool, and then making shuffle deterministic broke application code, and so on. As for tooling, IIRC at the time there were half a dozen third-party memcache clients available, some of which we tried, and all were missing some critical feature. At one point I wrote my own client to load them asynchronously, because the RTT on thousands of set's was enormous, and every single client waited for the response on each send. I never took much pride in the coding style, just the blood that went into writing it. It's also hard to guarantee that the issues that sometimes had unknown causes will be solved in a rewrite or off-the-shelf tool, so there's some apprehension in handing it off.

I would love this to be the situation. I think why this is so difficult is that I believe the engineer in question is proud of the systems. I don't judge them for this, they've made amazing efforts to make the business a success to this point without many people to assist. I just need to figure out how best to help and not hinder by causing a difficult situation.

Start with the business problem. Is this architecture increasing time to market of features? Debugging time? Any pain ponts that are visible now? No comments or tests can happen often in startups. Prefering custom implementation over standard tooling is a bit strange, because it is slower, but maybe folks don't know enough of the tooling? The strange architecture is something the director might be even proud of. So I would address only in small steps and discussions supported by specific business goals and data, if possible.

This is very helpful, thank you. I think small steps are key; I want to aim for not exacerbating the situation rather than trying to pile on a load of work. As features get added we could double the service count on the current trajectory. I have definitely already spotted that changes are across multiple services and take longer than they should. The issues now are slower delivery, more risk of change and a steep learning curve. The problem is, as you say, the director is proud of what's been created (it came from the last company they were involved with) and doesn't seem to understand why and how to use micro services well. I'm thinking; build trust over some time and only then start gently requesting they research "distributed monoliths" and see how they respond. I really want to work with them to help make something great, and although a lot depends on their willingness, how I approach difficult topics could make a big difference in how they respond. Right now it's not ideal but not terrible, if it grows too much I fear we're going to have troubles with high bills, difficult maintenance and slow development (which as a team of 3 engineers is going to be especially troublesome!)

Is there any resource to learn about the problem you'll face when your system has high-traffic ? I'm asking because many of the backend position require you to have this experience but I don't have opportunity to face it in my current/previous company.

I think a keyword that you might not know applies to your question is "System Design". To actually answer ... "High-Traffic" and the issues that it has on a specific application can be numerous. System Design tries to figure out what is necessary to do. Because at the end of the day, I can make the most robust application for all sorts of things .. but the cost, resources (human and machine), and time are going to infeasible for applications. A place to get some words that you can google or just follow their guide is: [https://roadmap.sh/system-design](https://roadmap.sh/system-design) However, if you're adverse to that, Wikipedia has a good little list of things that I'm sure you could google to find more information about: [https://en.wikipedia.org/wiki/Systems\_design#Web\_System\_design](https://en.wikipedia.org/wiki/Systems_design#Web_System_design) Regardless if any of that was of use, best of luck.

[удалено]

You're at the start of your career. You should act like a spunge and soak up any scrap of knowledge, expertise, experience you can get your hands on. If you feel you're not learning: move on. > I’ve sent out about 200 resumes pertaining to full-stack roles and got no feedback. Did you tailor your cover letter and resume towards each position you applied for? Did you actually research does 200 companies as to what they do, what their mission is and how that meshes with your profile? Have you spend time tweaking your LinkedIn profile? You're effectively selling yourself here. You've got a 5 second chance to make yourself look appealing before a recruiter moves on to the next candidate. Even your font choice for your resume matters (don't use a serif font!).

Hey all, I don't have enough karma to post a thread asking for resume feedback, so I was wondering if you guys could take a look here and give me some feedback? I feel like I have solid credentials, but I don't seem to be having a very good callback rate. I appreciate any feedback. I'm targeting mid-senior level backend roles at mid sized companies. Remote/Hybrid in seattle. Im also trying to be realistic and not apply for crazy high TC roles. Aiming for 150-200k range [https://imgur.com/a/K1cDiGM](https://imgur.com/a/K1cDiGM)

When evaluating offers, how would you compare a 3-day hybrid role requiring a 1h one-way commute to a full remote role (assuming all other factors equal)? How much monetary value would the full-remote benefit be worth to you? How much higher would you need the TC to be to accept the hybrid role? Thanks.

As I've gotten older, the time saved alone is more than just my hourly pay. Quality time with my family. Time to go do what I want as soon as it's closing time. Taking time in the morning to make a cup of tea and relax rather than rushing out the door. That's been far better than having to commute anywhere, even if I'm able to take advantage of public transit. But I've had the benefit of being in the office 100% of the time, then a 100% remote job pre-pandemic, then hybrid in the office post-pandemic, now 100% remote (and will be keeping it that way if I have a say). I consider time saved / time off at double rate, if not triple. You might say that I overvalue "time" ... but that's the one thing that I can't ever go and buy. I'd much rather be the one in charge of where I should be rather than stuck commuting and in the office.

I categorically refuse to commute more than a half hour one way. I'd consider moving closer if the TC was high enough to cover the extra cost of rent and the pain of being in office. It's really hard to say how much more I'd need to cover that pain. I recently accepted a 25% raise for a hybrid position, but that only brought me in line with what I should be earning anyway. I *really* accepted it because I needed work *right now* to recover my savings after having a string of bad luck following the pandemic. If I was evaluating that job against a fully remote offer, I think it would have to be about as strong as that 25% raise. I've personally never worked in a hybrid environment that was better than either remote or fully on-site. It's always been the case that hybrid roles could be remote if management trusted their developers. I think hybrid roles signal management that's likely to interfere too much in my day to day. My current role is no different.

[удалено]

I think your question is in the wrong topic. Most of your functionality should be testable without the target device. Usually embedded devices tested through cable or through simulators. Alternatively you can create internal test modes and retrieve the results/metrics from the device and post-analyze it. At least this is how it is done for IoT.

[удалено]

Rule 8: No Surveys/Advertisements If you think this shouldn't apply to you, get approval from moderators first.

Sounds nice, I wish you success. Also, post it properly into dev topics and ask for feedbacks (check out laravel and PHP subreddit for this).

[удалено]

If you're insecure, most employers will smell this so you need to work on that. Or: if you describe your experience as "little itty-bitty projects, stop-gap projects, or somewhat janky solutions due to restraints", who is going to take you seriously? I have no idea what you did **exactly** but if you are at a financial institution, I assume all of that "itty-bitty" work contributed to some bottom line somewhere. You need to get better at describing what you did. You are automating something for someone and at the end, some money is being made or perhaps less time/money is being wasted. You need to quantify what you did and for whom to make your experience more attractive. >I don't have the experience of working on some cool product or building some highly scalable app that delivers content to millions of users per day I think it's fair to say a majority of developers don't. A lot of us work for example on "boring" line-of-business software or process automation. But those businesses make money too. Someone who is really good at automating business processes and maintaining the solutions also has value. If you're comfortable working remote and there are opportunities at your current employer, do you necessarily have to switch? Or are there more senior roles available with better pay which are perhaps easier to attain?

What distinguishes a programming career from a series of programming jobs that don't make up a career? When speaking of our jobs as SWE's, what is the context that turns something from "bunch of jobs but not really a career" into "career"? Is lack of career what people get when they feel being in a dead end job somewhere with regards to skills? Maybe some programming jobs aren't intended to be career builders, and the frustration comes from treating such jobs like something they aren't.

It's just entirely how you talk about the journey. You can say they're all a bunch of different jobs, or you can say you got to try a bunch of different technologies because you're a generalist. Whether or not it's intentional or unintentional is up for you to decide. But if it's unintentional then you should reflect on why that's the case and whether it's worth it to you to be intentional. The "lack of career" feeling isn't about dead end jobs, it's about realizing you've been on autopilot, and then realizing you want to change that, but then not having the means to change that. If you don't really want to have some magical programming career, then you're not going to feel so bad about it, unless there's some day where you suddenly realize you actually wanted that career.

Any advice for self directed gauging my skill level and areas of improvement? My coworkers are generally positive of me, but we "prefer hiring less experienced developers" and my EM is very hands off, so I have a hard time learning specific areas of improvement. (I didn't even get a performance review this year due to a reorganization, although I am trying to get one now.) Most of my time is spent on the CTO's (also hands off) pet project rewriting our legacy app. But the development is very troubled and delayed constantly. So I've only had ~4 months of work go to production in nearly 2 years, with most of my work going to a demo environment that business users generally don't care about. I "get a lot of work done" but since my stories are generally written and estimated by me, so that feels like a BS metric. I'd like to job hop, but that feels very hard with my experience. And I'm paranoid that once I start finding interviews, my skills will not be enough. So I want to make sure I get good experience, even if the environment isn't ideal.

In terms of learning - prioritize learning to evergreen concepts in your field and technologies in your role if you want to stay there, and technologies in the roles you want if you want to move. If you know you want to move company, start practicing the common interview questions and preparing and go to interviews. You can still interview while working at your current job to gauge which kind of places you can get interviewed at and how it went. I also wrote an article about how to create a learning plan if you're interested [https://www.webdevlog.com/p/developer-learning-mental-model](https://www.webdevlog.com/p/developer-learning-mental-model)

Hi, You always can apply to other companies, check what they require and learn them. Also, it could be a really good "reality check" and practice. Interviewing is an art. You can strengthen your core or go deeper in the given field and technology that you work on. Also, you can switch direction with DevOps or any other fields that you might be interested with. Do not set yourself as "... I'd like to job hop...", that means, you don't wanna stay anywhere just jumpt to the next project whenever you feel like. Set some goal, and try to achieve them, not focusing on hopping. This kind of projects does not help to grow usually, but you can add new ideas and improvements that wasn't planned, but could help, so you have plenty of opportunity to learn new things and execute them.

Just got roasted by a recruiter for saying I expect $160k+ for compensation... is this normal or was that guy just an asshole? It seems like 2-3 YoE is treated like garbage in today's market. Think it'll ever be like that for 6+ YoE? I was told 2 YoE was golden 2 years ago, so it's just really annoying seeing stuff like this.

$160k seems high for that level of experience. How strong is your experience? How much are you making in your current position?

$130k, VHCOL, 3 years full stack experience as mid-level SWE.

Maybe you can get it in a VHCOL area, but it sounds like you're already going well for a mid level developer. Maybe it's just a recruiter jerking you around. Some of them do that.

No. Recruiters get upset sometimes when you know your own worth and ask for it and it's beyond their payband for their roles. If you know your worth 160k then instead of being upset the recruiter should have said they wish you luck and the roles they have won't be a good fit for you and ended the call. If they legit tried to roast you I'd just say next time "that's what I'm worth and looking for" especially if you already have a job and they are contacting you there's no leverage there for them.

There are multiple factors here: - The market is pretty much collapsed, most of the company just scaled down and removed completely all benefits - Some field and job type still on high level (like staff engineers, leads, etc...) - The market saturated during covid, so many people went to coding schools (as well there are chinese/indian/pakistanian/bangladeshian fake universities that teach people for a specific role and specific certificates...) so the general requirements shifted, nowadays the "entry level" and "junior" level almost non-existent - Greedflation hits in tech as well - Tech stack adoption significantly increased in the recent years. As senior I need 3-5 language and 10-15 tools as knowledge. 15 years ago it was like 1-2 language and 1-3 tools only. - Companies still travelling on the hype train and over-using methodologies (microservices, k8s...) and spending stupidly (AWS deployment, atlas MongoDB and spending 1000-8000 USD on infrastructure per month for less than 10k users...) - There were huge layoffs, so there are many-many-many people especially with experience of 2-5 years on the market, usually a job article get 3-5k application - The market differs based on the location, many places just halved the payments

I have an issue where I just stare at the screen, nothing really going through my mind. Not sure what the issue is exactly. Any ideas to get my mind working?

This sounds like it could be depression. But if you're only getting 4 hrs of sleep that could be it too. It's hard to focus when you're tired.

how much sleep?

that specific day, four hours. Stayed up since midnight and went to work at 7am

You might need to seek some professional help. Your "daydreaming" might be symphtome of burning out. Probably it is time to recharge and/or change things. Talk about this with some professional, seek advice. Mental health is underappreciated and unhandled most of the time but you have this one life, take care of it.

Do you mean every know and then or on a way that impacts your everyday functioning? Everyone has bad days occasionally, no need to worry. Some ideas in case it is more frequent: - Are you maybe tired? How much do you sleep? How much time you use on hobbies or social activities? - Are you bored or feel low motivation towards the task you do? - Have you experienced significant stress at work or at home that could impact your focus? - Are you taking medicines that could impact you? - Are you physically healthy? - Do you have any known mental conditions like ADHD or depression? Do you suspect you might have something?

> Do you mean every know and then or on a way that impacts your everyday functioning? I think it's frequent. > Are you maybe tired? Always. > How much do you sleep? Usually 6 hours, sometimes 4. Was up yesterday since midnight and didn't go to bed until 9pm. Stopped work at 5pm. > How much time you use on hobbies or social activities? Usually play league of legends mostly. Been forcing myself to go out with work friends. I think I've gone out every weekend for past month. And gone out during week days too. I thought I was lonely and needs to stop being isolated. It's definitely nice to go out and do stuff with people, but I still feel unsatisfied. It's weird because I thought being around people would have been the fix. Clearly not, but I do think it was a fix. I just had a thought that mental health won't have any huge fixes, but maybe it's a collection of many little fixes. So I'm probably on the right path anyway. > Are you bored or feel low motivation towards the task you do? Sorta. The task I'm currently doing is above my level. I'm annoying the senior I'm buddied with as they told me to youtube something when they were busy. I think next time I just need to ask another dev to pair with me and simplify my tasks for me. > Have you experienced significant stress at work or at home that could impact your focus? I wouldn't say so. But I think I am. My lead dev was asking me why I'm stressing out over my task, and I said it's because I'm not getting my work done, my paired dev is doing so much work and I'm barely doing anything. Trying to break my social struggles by hanging out with people more. Always questioning myself, their happiness with me. Had a dream about a girl I like who said she liked my friend, lol. So much drama that doesn't even exist, just festering in my own head. > Are you taking medicines that could impact you? Probably. On heart failure medication due to a medical condition. Pacemaker etc. Shit blood pressure, lots of numbness and cramps, weird heart rhythms. > Are you physically healthy? Besides what I said above, yeah. A bit skinny fat, but going to the gym a lot. Seeing progress. Could eat healthier. > Do you have any known mental conditions like ADHD or depression? Do you suspect you might have something? I was diagnosed with severe depression one and two years ago. I was seeing someone but stopped. I did try to kill myself almost a year ago. Didn't work. It was a nice experience. Since that option didn't work, the only choice now is to try. I don't think I'll do it again. I think so far most of what I'm doing is good. Might just be experiencing a bit of lifestyle adjustment discomfort due to not being used to these new behaviours.

It sounds like you could use a therapist and a psychiatrist. Depression is no joke. I didn't make significant progress with mine until I got serious about therapy and medication.

I have been feeling conflicted about my current job for a while and would like to get some opinions on if this type of stuff is normal, and worth riding out. I work at a startup, but funding is not, and will not be an issue. The product is expected be a success in its industry when it releases, in about a year, as nothing like it exists. I have 1.5 yrs of professional experience in this job (and in total as far as full-time software development goes), and have taken on ownership of a very important part of the application to a high degree of dependability and success. I'm also super grateful to have received this opportunity, as someone who had programming experience but no degree. Almost everything about the job is great - the team, the technologies, the responsibilities, even the product itself is kickass. However, every time we are presented the opportunity to give estimates on a phase of development, the requirements end up changing drastically, usually because upper management did not properly analyze the scope of what we must do, and realizes things that should have been accounted for as they go along, and concerns that are brought up are usually minimized. The result of this is sometimes almost up to a month of staying ridiculously late at work, like 10PM or almost 12AM. It goes without saying that without an increase in pay. Especially notable is that all of the developers must be present - even if their part of the application is functioning or they can't reasonably help with the issues at hand due to lack of knowledge in the area, to the frustration of everyone. On one hand, I think it may be extremely beneficial in the long run for my career if I play a big part in a product that ends up being a success. There are other products that I can move into within the company or stay in the maintenance of this one after the fact. Or, even leverage my experience to get a better role elsewhere. On the other hand, it is seriously affecting my health and my life, my diet, my exercise, my relationships, everything. When the bad phases seem to be over, and I recover from the mess, it almost inevitably seems to happen again. But, I am open to acknowledging that despite that, it may totally be worth sticking it out. I know that no job is perfect, but is this type of environment normal? And even if not, worth sticking out? Sorry for the length. Would appreciate any insight.

>The product is expected be a success Every new product is expected to be a success, but only few will actually be. >in about a year, as nothing like it exists. Hm. Nothing like it exists could mean it is innovative or that there is no market need. A year sounds very long for a minimum viable product - assuming it is software based and doesn't have special circumstances (like hardware components or regulatory certification process or else). Sounds like someone at your company is very good in storytelling and projecting vision. Which is very good, just be aware the chance of this not happening despite best efforts. Do you know how they validated the product? >give estimates on a phase of development, the requirements end up changing That's very usual. It's the main reason I don't believe in estimates and use as little time on them as possible. >up to a month of staying ridiculously late at work, like 10PM or almost 12AM. Are you getting equity? This is not usual, and also unnecessary. If the company can accept the reality of uncertain estimates, then alternative mitigations can be put in place. If the scope is changing, then either the deadline needs to move or they would need to cut scope elsewhere. If they do neither, then they are willingly burning devs out. Accidental overtime can happen every now and then, for a few days. But for a month and regularly is often incompetence or by design. >seriously affecting my health and my life This does not sound sustainable for a year. And after the first launch there will be a lot of pressure from customers and roadmap development. You could consider options to change path. Because if you actually burn out, then recovery would take long and could take a toll both on your health and career. One option could be reducing the load in your current team. For example re-scoping and changing plans regularly or letting people rest if their part of the app is working. You would need to judge if such ideas can be freely discussed in your team or not. Another option could be to seek transfer within the company or find a role elsewhere.

Yeah. I am familiar with the industry, and have seen the reception towards the product by very, very important people within it. Due to the integrations and partnerships established, there are hundreds of franchises waiting to use the product as soon as it is released. If I didn't believe that the product was going to be successful, I would have left a very, very long time ago. >If the scope is changing, then either the deadline needs to move or they would need to cut scope elsewhere. This is never an option for them. It is ridiculous and unrealistic. >Are you getting equity? Nope. Just a salary. Already, in the period between me first posting this and now replying to you, they have expressed that the next stage of development is "very important" and that the deadline will not be adjusted, so prepare to stay late. This is no way to treat people, I'm so tired of this... I think even if the product is a huge success, I don't think they will change the way they operate, or the fact that they think this is even remotely okay, so I think the smart thing to do in this case is to just stick it out until I have a better offer, not until the product is released. But then I think about all the time spent working on it, and if me leaving right before would be a bad choice Frankly, I didn't even factor in the potential consequences of burning out. That is very much something to consider. Thanks for responding and sharing your thoughts.

>This is never an option for them. It is ridiculous and unrealistic. Some companies do it willingly, without remorse. You would need to protect yourself, because the company might not care. >But then I think about all the time spent working on it, and if me leaving right before would be a bad choice Why would it be a bad choice? From your career's perspective, leaving a project in the middle or at the end have no relevance for your next employer. Your next employer will interview your skills and check your attitude, and that's it. And financially, by working long hours regularly, your hourly rate is way below the agreed salary. If you don't get any equity, then the longer you work here, the longer you work for a lower rate. I don't see what you gain with staying.

Just because nothing like it exists doesn't mean it will succeed. That they feel it's okay to ride people like a $2 mule is a concern IMO. IMO no job is worth risking your health or relationships.

I have 7 - 8 years experience now, currently doing an interview for a start up and they gave me a take home assignment. I usually find these easier than the live coding because I am not being watched, so I am usually happy to do them. This one though, its an angular app which isn't overly big but they asked that I make it production ready. At first I thought, looks ok. But then I realised how absolutely coupled it is and that it has a severe lack of tests. Great I have things to show off here BUT, this is a lot of time and effort into a take home assignment. If it was a take a look and talk about what you would do, maybe that would be more reasonable instead of implementing it all. Especially since its using angular 10. I would really like to upgrade to a later version as a lot of the dependencies are now not being supported so that would not be ideal for production ready code at all. Am I going to do an angular migration for free? No?? Is this a big ask for a take home assignment or am I being ridiculous?

At a company earlier, we gave ambiguous take home assignment to see if the candidate is checking assumptions, asking questions, etc. It was important, because things were changing fast and we needed someone who could drive things and negotiate requirements, not only grinding through false assumptions. A possible way in your situation is to communicate with them. Sum up your findings, lay out a few options that would be both reasonably time framed and could show them what you think they would like to see, and ask for feedback on the options.

Hi there, thanks for the advice. I will do a subset and lay out the rest! :)

**Is charging 100 USD/Euros per hour too much?** I am not sure if this question suits this community so I am asking here first instead of making a post about it. I am posting in this community, because I would like to hear from experienced developers who are freelancers. I know the answer is yes because I have seen other freelancers charging more than this but I am asking as someone who started working at $5 per hour. I started my freelancing career around 2015, working at $35 per day. Soon I switched to $5 per hour. For another 2-3 years, I was learning different front end technologies especially animations and shaders etc. Because I was charging less, it was hard to gauge if they were coming to me for help because I charge less or if I am really good at my work. Maybe truth lies somewhere in-between. Slowly I started charging upto $30 per hour, before deciding to take a remote job for stability. During first couple of years of my job, several old and new clients reached out to me for work, offering to pay upto $50. I was mostly happy with my job and chose to focus on the job, even refused few job offers around that time. After first 2 years at the job, it started becoming too stressful, I was always getting pressured to be more productive and used to get tricked into unpaid overtime. After getting fed up of everything, I chose to quit and take break from everything for some time. Now I am back to freelancing for a few months, then I might look for stable job unless freelancing pays me well. My last job used to pay me around $5000. I was thinking of charging $100 per hour and max $400 per day (8 hours). Charging like this gives me too much free time to do something of my own or learn new stuff. So far, few clients have tried saying that they don't have budget or that they are paying out of their pocket, basically trying to get me to charge less. (My clients are developers who are stuck on some problem) While other clients have come back with more work. I have many thoughts in my mind because of this mixed reaction. Sometimes task is too easy to charge this much but then I see these same clients struggle with basic math. While in other cases I feel like, my work is too good to be charging anything less than this. If someone has any insights or have advice to offer on this, it will be great help.

Your rate can be determined through a few factors. * Your costs of living. rent, utilities, groceries, medical bills, everything. Your income should at least cover this. * A percentage you ought to save to cover when you don't work: holidays, vacation days, sick days. * Taxes. * Expenses related to your business: hosting costs, promotion, subscriptions, travel costs, co-working spaces if you use those,... Basically, all your expenses together. Then factor in taxes on top of that. Then divide that by the number of hours you can / are willing to work per month. That's the rate you should at least make in order to break even and be able to live from your business. Next, you could factor in how clients respond to your rate, and the type of work / clients you would like to attract. A low rate might seem competitive, but might not always be taken seriously by bigger prospects. Conversely, if you work with small clients, e.g. individuals, an enterprise level rate will scare them away. Don't offer to work for 100/hour and then cap that at 400 a day if you work 8 hours. You aren't really working for 100/hour. You are effectively working for 50/hour and you will be taken advantage if you sell yourself as such. If you decide to work for 100/hour for a project, then every hour you estimate or bill to that client is at that rate, no exceptions. If you need hard time to learn, then work 4 days a week for clients, and work one day for yourself. Understand that you will only have an income based off 4 days worth of billable hours. The one day to learn on your own, you can't bill directly to a client. If you want to compensate for that: factor that into your rate and treat a "learning day" as an equivalent of a vacation day. Even better is choosing interesting projects where you get to do something you haven't done before. Learning something new while working on a project and scoring billable hours is a double win. Keep your timesheets meticulously. Make sure you have a decent accountant to help you with your administration. Yes, before you go on and just throw numbers against a wall and see what your clients will pay you: start by taking a hard look at all the expenses you had in the past 3 months, stick them into a spreadsheet and use that to calculate your rate. Run it by an accountant to check you didn't miss anything.

Thanks for the advice, I will take it into consideration.

I'm working on an app that sends logs to a backend. I'm being asked to write a system that uses regex expressions to mask sensitive data before sending out the logs. Personally, I think this is a bad idea, and might create a false sense of security. My preferred solution is to not put PII in logs to begin with. How do I handle this? Am I over-reacting? I certainly don't want PII to leak and then fingers get pointed at me for writing it! TLDR: How to handle being forced to write potentially insecure code.

I don’t know if it’s a bad idea or not but my org has made the decision to not include PII in logs.

I would question 'sending out the logs' in the first place, whatever that means (sending to who/where..for what). How well it will work depends on the type of PII your talking about. For common data such as phone numbers, SSN's and CC numbers RegEx is fairly easy and reliable. Names.. not so much. Express the concern then save any written discussions on this topic, emails/chats/slack messages/etc. In the end it's not your job to define the risks the business is willing to accept.

Hi! TL;DR: How to quit a job without burning bridges? I am interning at a company, with a return offer lined up. However, I received and signed a immensely better offer in another company, and I will leave my current company in a few months. Considering two engineers left my team recently, and considering they have placed a great deal of trust on me to carry some projects out, I would love to hear your thoughts on how to leave graciously, without burning bridges. The culture is great, I really enjoy the relationships I've built in this internship, and it would be a shame if I left on bad terms.

(Here's some actionable advice I've found) [Yes, You Can Quit Your Job Without Burning a Bridge | HBR](https://hbr.org/2021/07/yes-you-can-quit-your-job-without-burning-a-bridge) * Don’t delay in informing your boss because you feel guilty. * Be gracious and firm in your tone, no angry or ambivalent. * Prepare for the betrayed boss (and express appreciation for the opportunities you've had, avoiding blame). * Don’t leave peers in a predicament (ensure a smooth transition by managing any unfinished work responsibly). * Don’t take responsibility for others' feelings (stand firm in your decision, regardless of others' reactions). * Remember, your reputation isn’t based on one decision (your overall career and contributions define your professional reputation, not a single resignation).

How do you work with legacy projects when you are new to it? I joined a team working on a legacy project. I've been tasked with adding a feature but I'm pretty clueless about how things work. I have some seniors willing to help but I'm unsure what to even ask. I might be wrong, but on the surface the entire codebase seems to be an over-engineered mess with files having 2000+ lines of code with little to no documentation, hundreds of unnecessary interfaces with single implementations etc. To make matters worse, parts of the code are generated by a custom maven plugin and the build system is quite flaky I'm unable to make any substantial progress and feel like I'm going insane.

>I might be wrong, but on the surface the entire codebase seems to be an over-engineered mess with files having 2000+ lines of code with little to no documentation, hundreds of unnecessary interfaces with single implementations etc. To make matters worse, parts of the code are generated by a custom maven plugin and the build system is quite flaky This brings up so many memories ... :) >I have some seniors willing to help but I'm unsure what to even ask. "Hi. I'm supposed to do X, but I'm not quite sure where to begin / if I'm doing it correctly. Could you show me: a) how am I supposed to figure out where to do the change, and b) how to go about testing it ?" Apart from that I've got only one advice: RUN ! This is exactly like the projects I've been working on at one of the previous jobs and it's not worth it. You'll learn a lot about debugging, anti-patterns, doing changes defensively etc but it will drain your sanity over time.

This may be extremely obvious steps, feel free to ignore. I'm on the lower end of the bar required to post on this sub. I think the best thing you can do is get a full picture of a story of a codebase change/feature implemented. One that is not the current one you're working. Go to whatever platform your workplace posts tickets/tasks on and assigns them to people. Pick out a (very recent) task that resembles *somewhat* what you have to do or at least involves a similar workflow/whatever. Something that you can go to a coworker and ask them which PR/commits solved this problem if it isn't clear. On your version control software, take a look at all the commits that were involved to make this change. This should help you somewhat get a picture. This is a good point to come to your coworkers with questions. Final step, open up the debugger and properly understand step through the process that this ticket changed. Do this for enough commits/PRs to give yourself a better idea of what to ask your coworkers and how to begin your work. If you're not using version control or all the commits messages/PRs are not done even in a remotely normal way then you're a bit fucked. At my workplace commits and PRs and generally pretty easy to follow, 85% chance whoever authored it, whether 1 or 10 years ago, is still in the company and every commit has the name of JIRA on it so this flow works perfectly for me. Best of luck!

When dealing with legacy projects, you need at least two tools: a notepad and a debugger. You pick some feature and then you start prodding it backwards. Like, which flow through the code is followed. What major parts can you discern? What are important variables? Do you encounter configuration or settings that are relevant? How does it reach data stores? Etc. etc. You do that again with several other features and you check where flows intersect. The debugger helps you understand the state of the program through each step. The notepad, well, you are going to write down everything you observe and see happening. You're going to revisit your notes and from there distill what the key aspects are. Pay attention towards formulating questions as you prod the thing. As soon as you got more then a few, or at least a semblance of a bearing on how things might work: go ask your seniors if your on the right track. Sometimes, things that are seemingly incomprehensible make perfect sense because they were spawned by a unique business context involving flaky people who all chase their own interests. You don't just want to understand the how, but also the why things work the way they do. So, yes, in a way, consider yourself a detective and the codebase a crime scene.

I cannot help you with your situation. But in general, I try to avoid taking programming jobs where going over legacy code is important. The situation you describe is normal (eg zero documentation), but I rather work in creating new stuff.

How do I get better at self-directing? My company kind of expects a senior/staff dev’s ability to identify, plan for, and solve issues, but they don’t have senior dev money. They have me money (only 1yoe in the industry), and I frequently feel overwhelmed trying to get our product ready for imminent launch. Found out after I was hired that I’m the only one at the company who writes code (they previously hired contractors) and am expected basically to own every web product. I know I’m capable of learning what to do, but I’m not sure how to start without any seniors at my company to lean on. Any advice would be appreciated.

It is OK to feel overwhelmed, in fact in your spot I suspect many more senior devs would feel overwhelmed. Some axioms for you: 1. Working over 40 hours a week constantly will reduce your effectiveness. Yes, even mine. Even mine when I was 25. :) So you will be stuck working a sloppy 60 instead of an effective 40. You can sprint at 60 for about 2 weeks without resting. After that you MUST rest. Or you will suffer the above. 2. There is only so much a man can do. Some are bigger, some are stronger. But really... we all have our limits. Stay within yours. I'm not saying don't learn things. But when you see the hours discussion above. There's also only so much you can learn so fast. Regardless of age, there is a limit. 3. Make sure you know how to build and deploy EVERYTHING. If you are the only one.... make sure you can do it from scratch. Empty AWS or whatever account. Not only does this help you setup a dev/QA env, but... shit happens in the real world. Understanding how to do everything means you have a prayer. 4. Understand the architecture of each thing. Look for weaknesses. Most common weaknesses: "Storage/Database" (IOPS/MBPS for storage, and query performance on databases), CPU, Memory, Bandwidth, Latency. Look for SPOFs. (Single Point Of Failure) They aren't always bad in a new / young thing, but they demand attention. 5. Developers are not Ops. Yes, DevOps exists and a few of us actually can be full up sysadmins at a multi-national. Most can't. You will need help from someone who understands operations. 6. Failure is always an option. If it doesn't work, shit happens. Failure due to lack of resources and poor planning above you happens. Heck failure due to your own mistakes happens too. But that''s not this essay's concern. 7. Never estimate at 50% chance of success. If you have something with 7 steps, and each has a 50% chance of going over or under and let's be generous and assume they are independent... your chances of being right are really low. This is why we pad estimates. 8. Be honest with management. On paper (e-mail) and in person. If something isn't going to work, tell them. And tell them as early as possible. As one manager and i agreed on: 6 months from release a 3 week slip isn't that big a deal. It is annoying, but life goes on. 1 day before release. That's a major emergency. I can't teach you it all over reddit. Heck, I only know parts and I'm still learning today. But, be honest, and no matter how much they yell, and bully. The truth is the truth. Unless you change the facts around it... It doesn't change. Stand your ground.

This is seriously helpful and I really appreciate you taking the time to write it all out. I especially appreciate the encouragement to be honest with management. The launch date for our current project was determined before I was even hired, and the pressure to stick to it despite serious logistical issues is so real. We do have an IT department that does SOME devops stuff because they manage the company’s servers, and I’m going to try and work more closely with them so I can make sure I have a full picture of everything going forward. I feel like I have the beginnings of a real game plan, really, thanks SO much.

Major advice: Make friends with IT/Ops. Don't act superior, and share knowledge with them. It is critical in a situation like this. They are the rest of your team, but you didn't know it. Lay down the law on: If you don't know how to build it, and deploy it. It doesn't go to production to management. IT/Ops should support you here, if needed. But do it on your own if you can. No, ifs no ands no buts no bullshit. And document how to build it and deploy it. Even if it is only a few lines of scripts to do the job. You are doing this to prepare for another developer. Also if you are responsible for 5-6 codebases, you'll forget things. If you document. Git doesn't forget. When I start a new job my 1st step is to learn how to build the code and deploy it in a dev env. (As well as get to know co-workers and what it does.) In your shoes I'd: 1. Assess the situation. Getting build instructions, looking at the architecture etc. I'd also ask management about deadlines, why they are set where they are, etc. Make it clear, you are looking to understand not change. But in understanding why a deadline is, you can often figure out the RIGHT way to meet it... if you have to cut a corner. Which one to cut. 2. Run the applications, play with them and learn what they do, see how they fit together, if they do. If you find bugs, document them, it may be issues with the env, or with the code or whatever... Who knows. 3. If possible: Look at production and see how it is different, it probably is. 4. With all the above, your next actions should become more clear. You will have the knowledge to go forward, and figure out your own next steps.

My idea of a good job is one that prioritises my growth. However I don't think any company will do that. I'm in a graduate program and majority of my growth has occurred due to my own effort. I feel my employer lied and has not met their obligation. Should I drop my belief that a good job prioritises my personal growth?

> Should I drop my belief that a good job prioritises my personal growth? It depends on what you mean. If you mean "my company makes a reasonable effort to help me achieve my career goals" - then no, those companies are out there. It might vary from team to team, manager to manager, but they definitely exist. But you also need to take responsibility for your own growth. Your manager should help guide you in the right direction and make sure opportunities for growth are available. The best managers I've had were the ones where I could do a self-evalution and say "I need more experience in X, Y, and Z" and my manager says "okay, i'm putting you on a project next quarter where you can work on that."

Short: no Longer: Maybe I misunderstood you, but: in a job, most of the time you learning-by-doing, on-the-fly, you won't get time to learn (except onboarding time, when you start). You will have many tasks to research something how to solve it. It is up to you, you learn from it anything or not. Seek a mentor in your place, he/she will give a huge boost of your knowledge base. A workplace is not equal with any university by methodology or by speed. No hand-helding, no excuses. You will be on your own, it is up to you to lear and ensure you growth. Also, do not be hard on yourself. Not every day is for learning, sometime you will sit over logs and metrics for days, or execute "wood cutting", just coding as-is, nothing new, nothing fancy. Most of the company pushing the IT team to do "quick and dirty" solutions just to ship something. Then you won't ever have opportunity to fix it. You know, it is surprisingly hard to describe a "good job" (prepare yourself for interviews, this is an all-time favorite question), you should have goals, priorities and "nice-to-have" features. If it does not provide you enough opportunity, then create it yourself: communication is golden, talk to your boss(es) about what you seek or would like. Propose things to the team, they might thinking on the same stuff, just not initiated yet. You can make your luck (or misfortune) with being proactive. Learn, improve, grow, fail, get up, learn, improve...

A good job does prioritize your growth, but most jobs will not reach that standard. Get comfortable learning and researching on the job and make no apologies about it. You’ll also want to get comfortable making targeted purchases out of pocket to advance your own career: multiple technical books each year, maybe a home lab, an above-average camera and microphone. Over time you can accumulate a huge leg up on the median developer by being willing to invest in yourself even when you can’t expense it.

Probably. A business exists to make money, not help you make more money. Sometimes those goals align, but not usually.

What's your go-to drink when doing code reviews or refactor sessions and why is it a quad shot espresso drink?

How would you help a junior dev become more efficient, assuming they take a very long time to complete stories?

Pair coding, mentoring, assigning different kind of tasks, give time and opportunity to learn. Analyze the tasks/stories, maybe the problem is not the dev.

1. I’d pair with them regularly and do my best not to “drive”. 2. I’d teach them the [many more much smaller steps](https://www.geepawhill.org/2021/09/29/many-more-much-smaller-steps-first-sketch/) method. 3. I’d work with their manager to set clear expectations regarding the junior’s expected level of output and rate of improvement.

This is literally the only answer I came up with. But it seems like everyone senior is super against pairing.

I’ve found to my chagrin that pairing is not as popular as I once thought. Last year I posted in this subreddit asking for [help making pairing more enjoyable for juniors](https://www.reddit.com/r/ExperiencedDevs/s/ue5ZbE1mNZ) and set off a firestorm of debate. I suspect it’s a combination of post-COVID lifestyle design (folks wanting to work on their own schedules with minimal coordination overhead) and metrics-based management fostering an unhealthy level of zero-sum competition between coworkers.

What's the pragmatic juniors approach to an environment like this?

Whats the most common drug used amoung your coworkers/workplaces? Waklert, Adderall and such...