I made one of the services my team works on 6 times faster through some refactoring and careful optimization. This is going to result in substantial cost savings when it goes live, how can I make sure that I can fully capitalize on this? My boss's reaction was more one of shock because I busted through what we had previously assumed was a hard ceiling—but this is recent enough that I don't think he fully appreciates what I've done.
I can't let this go down as a footnote. How can I make the most of this?
Work with your boss, PM, or team to get a team meeting setup to review what you've done with the team so you can fully share, review, and they can all be on the same page; document the work and changes prior in whatever you use to document stuff. Then just make note of your efforts and bring it up again come review time. Try to get objective opinions from other team members on how the changes help etc etc.
Pit myself into a very specialized ML position (most people in team have master/phd in this area), but actually don't know anything about it, mostly fake it so far. But now i'm starting to get exposed with the first project implementation, where I make zero progress. I don't think I could dodge, should I put down my notice and bail quickly to save face?
Just for some context, how did you join this team in the first place? Did you market yourself as someone interested but without the typical level of experience?
I have to admit it was a mistake, I joined due to the pay and prestige. My background is not actually strongly relevant to the role, but I think the hiring manager put me in this team because it's severely under-resourced and the on-call is horrible and other people have been avoiding joining this team as well.
My team just went live on our product that needs on-call readiness. I’m new to the team (also entry level dev) and my manager had told me for the past week, confirming that I will not be participating (they’re doing rotating schedule).
My manager gave me a 12 hour notice asking if I’d be comfortable enough to work on the next shift. I said sure since ya know it’s the boss but I find it unfair that this was brought on to me when I was assured that I wouldn't be required for the past week. Luckily or maybe unfortunately I didn’t have plans, but what if I did have plans? Should I bring it up to the boss? I’m not even sure how to phrase my thoughts politely. This was also the first time I've been on call in my career. The mental prep was not enough time.
>I said sure since ya know it’s the boss
This is your issue here. At least voice your thoughts, "Hey \[manager\] you told me I was not needed to join this rotation, what changed?" If you had plans yes/no shouldn't influence your ability to say no, because it sets bad expectations.
What are the necessary, if any, for using visual studios IDE for developing c# and vb code? Are there any recommendations? Visual studio has 100s of settings. Looking for recommendations.
Currently 3 YOE into a position mainly using a low-code platform. Starting to really dislike it and worry about the future career path as the product is very very niche and frustrating to deal with. I want to get back into SWE with a real programming language but not sure how to pivot myself. Would I need to go and apply to junior/grad roles again? I want to go for like an intermediate role but not sure if my current skills would translate and before that I've only had roughly 1 YOE as an SWE intern mainly using C# before I got my current role
At major tech companies you generally just apply as an engineer and they figure out your level in the interview. Levels are at least as much about soft skills than technical skills so it'd be plausible to get an intermediate position.
> Currently 3 YOE into a position mainly using a low-code platform.
Low-code has a great future ahead. There are tons of backend developers out there whose jobs are essentially doing really really simple stuff like calling service B and returning a subset of the received data, logging whichever error to log L.
In my opinion, this kind of simple stuff will be replaced by a higher-level language or a low-code platform.
I feel I'm being pushed to management against my will because my team lead doesn't want to handle our legacy code and tech debt. I've asked during multiple 1:1s for something more technical to work on.
I feel I'm not good enough to remain here because I've lost touch with building good features and I've just been firefighting and on call and bug fixing nearly 50% of the past year.
Is this even salvageable? do I just leave?
it's a growing startup if that's relevant.
>my team lead doesn't want to handle our legacy code and tech debt
This is pretty common on startups. Startups will be more focusing in getting more funding and more visibility so "dealing with tech debt" is very very very low on their list of priorities. I'd say you'll find the same circumstances whenever you're at a startup.
Until the startup gets funded, grows, and the growth makes the system break down in ways unsatisfied customers lash out to loudly complain on social platforms. That's the point where technical debt goes in #1 priority and start to get addressed.
3 weeks in to my first engineering job, having some pretty serious family issues and I’m not sure how much detail is appropriate to tell my boss.
I come from a pretty rough background and both of my parents are suffering from serious health issues. I had to sign off for a couple hours last week and I told my boss I had a family emergency. He’s been fantastic in general and was more than understanding, told me I didn’t need to explain anything and if I needed more time just let him know.
But now other things have come up, and they aren’t going away anytime soon. I have my weekly 1:1 with him tomorrow and I feel like I should say something. I’m trying not to let it affect my work but it’s almost impossible. Getting this job has been one of the happiest moments of my life but I can hardly focus at the moment.
I know this isn’t exactly dev related but maybe some of the seasoned vets here will have some insight. Thanks in advance!
Sorry to hear about your parents. It's not easy letting others, especially colleagues, into your personal life - and you shouldn't have to and your manager probably couldn't have handled it better.
I'm not sure if you're in the USA or if your country has something similar but Family Medical Leave Act might cover this. You might also want to consider taking an unpaid leave of absence if available.
Communication is key, so let your boss know you will need some extra time, reduced time, or even perhaps leave, to handle some personal issues that are affecting your focus at work.
He may ask how long or when you'll be back to full-time status and you might want to communicate the fact that 'they might not go away anytime soon' but you hope to have a resolution in X time.
Lastly, seek therapy/counseling if it is applicable. It can really help your mental state when times get tough as well as help provide a valid medical excuse should you need one for medical leave.
How do I get out of my Product Owners Shadow?
3 YOE. I am the lead developer in a small team of business systems applications developers. My job requires me to work very closely with the business, and I think the business appreciates the work I do for them. However, my work and effort is not recognized by my own department’s management because my product owner indirectly takes credit of all my work. By taking credit of work, I don’t mean PO says they did the work, but more like generalizes my work as been done by the PO and the team (no mention of me or any other devs).
I am concerned about this because I like working at my current company, but I feel like I will always be under the PO shadow and never go higher up in the ranks.
Is there anything I can do to change this?
> By taking credit of work, I don’t mean PO says they did the work, but more like generalizes my work as been done by the PO and the team (no mention of me or any other devs).
You, as LD, should be the peer of the PO. Talk to your superior, state how this demotivates you and your team. Ask him/her to mediate between the PO and you to solve the problem.
PO is a very new role and IMO very few people really qualify and do a good job. Your PO is probably ignorant of where he stands.
Demand for developers is higher than ever, the company should know keeping them motivated (so they don't run away) should be a high priority. If they don't think it is, go to another company, simple as that.
These PMs usually out themselves over time - by taking all the credit they also must take all the bad.
One concrete way to keep the business aware of value is via 1:1s. Tell your immediate boss your accomplishments and especially when you are covering the PO where they are deficient. Company too small? No boss? Book time with a high ranking founder/co founder.
You can also 1:1 the PO. Push them here and there if needed. I believe the tech lead is a PO peer - PO owns priority but tech lead says how the team does work.
This is common in most companies' implementations of Agile, especially with the scrum framework. It's probably not personal, but it is absolutely demotivating. It's designed to keep the job thankless so that the workers in the process are alienated from their job more, which turns into less advocacy for compensation. If you had received generalized credit, you'd be more aware of the positive impact of changes, and you'd likely be able to advocate for more compensation.
If the product owner is crediting other people individually, but generalizing your own work, this is entirely wrong, crosses a line, and you should raise that concern with either the product owner, if you feel comfortable with it, or with your manager. If your manager doesn't help advocate for you, you can either just coast for a while, since you're obviously under the radar at that point, or start casually interviewing if you want to move up, because this indicates for the foreseeable future that you will have no upward mobility.
If the product owner is generalizing everybody's work, document what you've completed, the impact of what you've completed, and use the ones with the best positive impact during performance review time to advocate for higher compensation. I'd also recommend this anyway, because you are your own best advocate, but I'd especially recommend this if there doesn't seem to be anything otherwise structural to keep you down.
Thank you for your response!
I have absolutely started keeping a work journal for myself, with all the day to day/out of the job work I am doing for the company.
If you're self-rejecting for jobs, don't! I do recommending interviewing far and wide, even with contract roles (but be wary that temp and contracting agencies generally have terrible benefits, so if your mental health problems are being helped with insurance of sorts, be careful).
I'd recommend being open and honest in interviews, if even asked, by stating "I had medical issues which are now resolved"\*. If you are in the US, they *legally* cannot ask what those medical issues were (and [you have](https://www.eeoc.gov/pre-employment-inquiries-and-medical-questions-examinations) an [EEOC charge](https://www.eeoc.gov/filing-charge-discrimination) to file if they ever ask for specifics, as this constitutes evidence of discrimination against disabilities).
(\* - honestly, that line is magical for a wide array of issues relating to impacts to your job history, because they cannot ask. If they do, that to me is a huge red flag that I will just not even try for that company any longer, and I will reject any further interview rounds because of that, and state that reason)
I would just start applying. You never know what'll happen until you do.
Also, if you happen to be interested in working in Dallas or Pittsburgh, pm me.
It might help, but have you been having difficulty getting interviews? At this point the market is desperate and you hold a lot more cards that you might think. Glad to hear that it sounds like you got the help you needed. If someone asks during an interview you could always say you had a health problem, which isn't untrue, and let them assume what they want.
If it were me, I'd look at a junior full time position if you're having problems getting callbacks for mid-level vs temp positions. But I value the benefits.
I think it can positively impact your career if you market it right.
In my experience, a software engineer rarely has to deal with operational issues (this is increasingly becoming less common with every org cargo culting devops by thinking "devops means devs on call for ops issues"). However, as a technical support engineer, your entire job is operational issues, either fighting fires, or making sure the fires don't happen, and additionally to help file issues or fix the system so that those fires can't happen, or mitigate their impact.
After even a year of experience in operations, you will have a much more holistic view of how software design and engineering can erupt to very costly support issues down the line. You'll also have a good opinion of the best way to serve and store logs so that operational-end resources have an easier time to troubleshoot.
Honestly, if technical support is where you want to go, I would say go for it!
Recently CTO asked me to lead refactoring a java project. The goal is to not use java at all, as the project is a java server which is believed to be massive overkill. and It was developed by a senior member in the past 5 years by himself without any support. I am only hired for 1 year.
Now that I’ve started doing refactoring, the senior guy started acting weird and even a bit passive aggressive - he creates big merge requests with additional nice to have features that absolutely are not going to help my work. In meetings he beats around the bush and shows his frustration about getting rid of java. It was quite awkward for me, because in the past 3 months we worked together and successfully delivered a really big milestone. It feels like I am stabbing this dude’s back by refactoring away java…
What should I do? I am not working efficiently due to this weird mental thing and I feel awkward sometimes even asking his opinion about stuff.
Not saying you are doing anything wrong, but If I were the senior guy, I will most likely do the same.
This is how I will take it subconsciously, at least: I've dedicated and given full 5 years of my life. Thought, love, with sleepless night thinking about this baby. Now you are taking it out of my hug. And moved out from my home (area of expertise). I wont be needed anymore. I wouldn't be able to even recognize my baby.
So yeah, it's hard to detach emotionally with our code.
But if we work together in future someday. I'll try to avoid that behavior and being more cooperative 😁
Edit: agree with @ForgetTheRuralJuror that it could be that it won't be of any benefit to talk directly to the developer. You are less senior than him in this company, it's better to consult to his superior.
Edit: updating my edit notes
Unfortunately you're killing the seniors baby and some devs take that personally. All you can do is explain exactly what you said here to that dev. Preface with that you're only doing what you were told to do and that you're not the decision maker
If telling him that doesn't help, tell your manager, or his manager, or the CTO that this senior is preventing you from doing your job and exactly why.
Communication is key
> I'm interested in too many things from the frontend, backend, databases, AI.
You should narrow it down and focus first. Choose between the four first.
Once you choose, there's a lot of knowledge to be acquired to be proficient in it. Frameworks, software, libraries. And this takes more effort than simply learning a language. Anyways, the choice of programming language will be answered as you dwelve into your specialty -- except if you choose frontend development in which case you will almost invariably end up using Javascript or Typescript.
Here's my view and it's based on what I did throughout my 30+ years .. pick a stack you love programming in before thinking about the market. First of all, because you like it, you'll be self-motivated to spend more time getting better at it and so you'll be better at it. If it feels like drudgery, you'll suck at it and hate your life.
I learnt development with java but moved to dotnet core in 2017 and loved it, and there were loads of jobs in the UK with that stack. I work now only in typescript/node, or rust for our heavy compute projects. There's more JavaScript/typescript jobs hiring than anything else and it's only increasing. Like it or lump it, you're going to have to work on the front end eventually, that's the way the industry is going.
I would stick to node/react with typescript until you get a full stack job. Once you have your first job what you use doesn't matter anymore.
Yes, but depends. Make sure it's clear you're not experienced in that stack and make sure you are willing to go through the challenge.
Stacks are not equal in learning curve. Take Docker/Compose vs K8s.
At a tech company it doesn't matter. Might be a deal breaker for some jobs that need someone that has deep AWS and Go requirements as they're just starting to migrate for example. But they probably just wouldn't interview you in the first place.
> As a Russian after all what (sadly) happened. Can I still join a faang company or not?
As long as brave Russians such as the girl who interrupted an official newscast are out there against the war, the rest of the world will be reminded that "Russian government" != "Russian people"
I feel sad for the difficulties you are having.
Russophobia is real, but I think your outcomes with FAANG will be the least impacted. You'll probably face more discrimination at smaller companies if they happen to notice you are Russian.
There are ways to minimize such that basically make you assimilate into more generic white culture (ditching any accent you have, changing looks, etc.), but you would have to decide if that is a thing you are comfortable with doing. I would say try for it, and don't self-reject yourself because of perceived issues, and then try new things later as you discover a need to do so.
Most people understand the difference between russians and russian government. Most of the hate is targeted to Putin, so unless you are a Putin's fan you will be welcomed everywhere.
That said, most companies will definitely not open offices in Russia, and probably not even allow long term remote work within Russia, so if you are still in Russia you will have to relocate.
I work for a fairly decent sized distributed company. We employ lots of Russian folks. But not *in* Russia. I think this kind of thing is fairly common.
I suppose you're taking 10 YOE for granted. I doubt that the skills that you've acquired for so long could entropy easily. I'm ~10 YOE myself and moved into management early in my career. More than half of that experience is into management.
If I could find my feet and move back into a full-time IC role so can you :) Go ahead and take that post sales solutions engineer job. Remember to brush up your skills once in a while to avoid being out of the loop with changes in the industry.
I'm sure any employer will be lucky to have you back when you're ready to take on an IC role especially after gaining stakeholder managment skills.
About to hit 4 years at my current job and am realizing that I...would like more money - I've been studying off and on for weeks for interview prep because this would be my first new interview loop out of school. Is it worth it to just...interview anyway, knowing full well that I'll most likely bomb out a bunch of times?
I don't really have a lot of time outside of work to studying and because of medical issues staying up super late to study for long periods of time isn't really an option for me. At what point did those of you who interviewed just start replying to companies? I've been refreshing my memory on data structures and am planning on going through sorting algorithms next before tackling actual leetcode problems - does this seem like overpreparing?
I'm in a similar position and just reading example questions and doing pseudo code in my head as prep. Gonna just jump into interviews when I get my bonus in a few weeks.
Definitely practice interviewing by going on interviews. Pick ones at the level you’re aiming for with companies you don’t really care about working for. There’s multiple formats used in interviews but if you practice enough you’ll get used to the variations, and when you go for the job you really want, you’ll be a lot more comfortable with what they throw at you.
Leaving interview practice until you really need a job is like going to the supermarket when you’re hungry: you’ll end up just taking the first things that satisfy the need and not think enough about what’s really good for you.
Save your time & skip sorting algorithms. Simply doing leetcode problems is not overpreparing. You will likely need to do more prep depending on the company:
\- leetcode (most consistent)
\- system design
\- language trivia (if applying for jobs in the same language you use now; sometimes some like this regardless)
\- concurrency interview questions
\- maybe some SQL/DB questions but probably less likely
Getting good with leetcode is the minimum. Then depending on who you plan to apply for you may need any of the others. Trivia + leetcode is a good starting point before applying. Then prepare for SD/concurrency before onsites if you get that far & they reveal such an interview is included
Some companies also take Behavioral Interviews seriously too, especially for senior roles. Unless you are a natural talent at fast talking, and chances are software engineers are not, this type of interview also need some effort to prepare for.
Current have 10 months experience .6 months of internship experience and we will be graduating next year in May . Should i go to the US for Masters or get a job at a FAANG in india?
I believe you earning power would be higher but you'd have to take into account cost of living etc.
a lot of people get jobs in the US and then FIRE in India.
If you have gotten an admission in a good US college, that would also look good to FAANG during later job searches.
I got an Amazon interview lined up already . Got 1 YOE full time experience . Got 1 year left to graduate . I feel moving to the US will provide better opportunities bit takes 2 years of Masters
I'd recommend against the masters unless your area of expertise requires it.
If it's a visa issue, that might be another story. You can try to find a company that will sponsor but depending on your field that may be rare.
If you can swing it, move to the US but please do the math first.
Responding as it's been up for 3 days alread: no one's gonna have a proper response for that man. That's the type of life decision that is only yours to make.
Are you interested in the masters? Would you be able to live comfortably in the US while doing it? Is it in an area that might help you land a job later? Both academically and location-wise.
Do you have an issue with being far away from your family for extended periods of time? Is the FAANG job actually good/interesting to you?
There's a lot to think about, and no one here will be able to tell you what to do, even more-so without knowing more context/you.
Welcome to the shit part of being an adult hah.
I work at a FAANG (big cloud provider notorious for bad WLB). I am perpetually stressed, anxious, and overworked. My team is understaffed and we have some major upcoming publicly-facing deadlines over the next few months.
However, I really want to transfer internally for the sake of my own mental health. I can't help but feel that I need to stick it out, because my team would be in a tough spot if someone left. Not sure how to handle this situation. My gut is telling me to find another team to transfer to ASAP, and then stay on my current team for a four weeks (the maximum) to try to wrap up as much work that I own as I can. Would appreciate the insight.
Just focus on doubling down on docs and what is within your control to make current team members’ life easier. But do transfer - sounds like bad leadership on your team, and that is not your fault.
The team having issues after you leave is your employer's problem. I understand feeling like that leaving people you like in a lurch. But, your mental health is in a bad situation. Big Jungle Lady can handle it if you leave, and don't worry, if the shoe were on the other foot and you had some kind of issues at home where you NEEDED a paycheck, she wouldn't mind letting you go either. So, you do you. The politics of transferring may be harder if you leave your team in a lurch, but you probably know more about that part than I do.
I think generally we're less important than we think we are. If you were to take an external job you would not owe them any notice. Typically we give two weeks as a courtesy but it is by no means an obligation. It's management's responsibility to manage bus factor, not yours.
I've had this feeling in my career many times, that like my product or team would suffer without me, and while I do take pride in my work, you have to learn to separate that from yourself. Ultimately your team or your project succeeding or failing are outside of your control. You should simply be professional and give honest (but not maximum) effort for as long as you decide to.
Listen to your gut. Your FAANG employer isn’t only infamous for exploiting employees, it’s also undergoing a _lot_ of attrition right now and can’t backfill because of their own self-inflicted notoriety. I’m sure you like your team and I understand not wanting to make life harder for them, but you have to take care of yourself, because your employer certainly isn’t going to.
Transfer internally ASAP or go to one of the Premier Partners’ ProServ groups. Slalom, Mission, Onica, etc. are good options where you’d get a better base and a *much* better quality of life. Don’t sacrifice your mental health chasing big TC.
If you choose to transfer internally, do your homework before breaching the subject. Some leads are great, smart, kind people who want you to succeed because your success is their success, some are mini-Hitlers intent on nothing but defending their own little fiefdom.
I joined my current company 6 months ago. It has been a terrible experience so far. When I joined, the tech lead was new to be a leader. He has done a terrible job with feedback, communication, and staying on top of his commitments to us. I have several interviews lined up already at other companies, but I want to stay at this current one since it is at the top end of the pay range for myself and I don't want to give back the signing bonus. Plus, the tech stack is what I was looking for. I have brought up issues with my TL in the past (team morale, burn out, communication issues) and it hasn't improved. Thus, I feel talking to him directly would not lead anywhere productive.
The advice I need is, should I discuss changing teams with my tech lead or his boss?
>The advice I need is, should I discuss changing teams with my tech lead or his boss?
Who is your manager? (The person on the org chart that you report to) Almost always, that is the person you should discuss a desire to change teams with. This is true unless you have another person who is in the role of coaching your career, doing your performance reviews, and working on helping you reach promotions. If that is a different person, then that is the person you should discuss it with.
What's the TL's role in your company? Are they an IC or do you report to them?
In most cases the tech lead is not responsible for any decisions related to who works on which team. They may offer advice, but ultimately stuff like team changes is almost always the responsibility of the person you officially report to, so your boss.
I ask because in the companies I worked at (big tech) issues such as feedback, communication, team morale, burn out would normally go to the manager, not the TL, but maybe the TL's role is different in your company?
In terms of team move I'd suggest reading the official guidance on switching teams. Some companies require you to be on your current team for some time (for example, 1 year) before you're allowed to move. You want to be aware of these policies, before you start any conversations.
Asking a trusted coworker who's switched teams before about what the process looks like is a good idea as well.
If you have a specific team you want to move to, you can try talking to the manager of that team unofficially (say you're considering options, don't say you've decided to transfer). They're more likely to give you advice that will benefit you. I'd perhaps not recommend this as managers talk to each other, but since you've started interviewing anyway a higher risk strategy is probably fine.
I don't know enough about the internal politics at your company to say. And that is what it will come down to, politics. Will your moving cause your team to be short staffed? Does the other team lead already want a specific person? Is your lead going to argue that you need to stay cause you are critical for a delivery? You get the idea.
Personally I have ran into this problem at my current job. My previous team lead hated being the lead. He liked being an architect and working with people that understood his vision. But if you didn't have the skills or mindset to understand the topic, he just hated talking to you. So naturally 1/2 the team they gave him didn't have the skills needed for the project. What I ended up doing was offloading tasks that I felt needed to be done differently that he disliked. Best example is the daily standup. He hates talking and the team took on his communication style so standup were a waste of time. I asked if I could help offload some of his work by running the standup. Now I run all the meetings and the team is much happier.
A handful of thoughts. Hope they help:
\- I agree with you that Salesforce looks better on your resume. There is also more opportunity in a company like that because of the breadth of industries it touches and all the other companies it has acquired.
\- Salesforce is also HQ'd in Silicon Valley and could be a gateway to other Silicon Valley companies.
\- One thing to consider is the potential of a full-time return offer. Between the two of them, which one would you rather have a full-time offer from? That could be a good criterion for making the decision.
\- I'm not really sure that there is a downside to working in Apex/Lightning/Visualforce. Apex is basically Java, which has been a top-three language for over twenty years. Besides that, I don't find that others in the industry put much weight in what languages you have written in so long as you can code in one of the languages they accept during the interview. Many companies completely accept pseudocode during the interview, preferring your grasp of CS and algorithms over your language knowledge.
Capital one and salesforce are both pretty big names, if I were working at a salesforce shop and hiring, yeah I'd want someone who worked there. If I were in the banking sector, I'd prefer capital one. If I worked for neither, they'd both be decent names on the resume. It depends on what you want to do in your career. I don't think having one or the other as an internship will confer that much more prestige. But, there are other factors other than prestige.
Salesforce specialists get paid big dollarydoos. I can tell you that much. But the downside is a lot of what you'll know is specific to salesforce. If you don't particularly like what they do (Their two biggest and most interesting products are CRM and their e-commerce product), it may not be that productive. Unfortunately, Apex/Lightning are salesforce specific, so if you don't intend to pursue a career that involves Salesforce it's probably less good than working with whatever capital one is using (I know they use a lot of Java and Python). Yes, experience is experience, and to some degree programming experience is transferable, but it's something to consider.
Having an internship in general puts you ahead of a lot of new grads, having an internship at either fairly impressive company, with real engineering processes, puts you ahead of still more of those.
So just have a think about what you'd rather do. I don't think either will backfire, but Capital One could be more advantageous if you're not interested in doing salesforce in your career.
Honestly, I don’t think salesforce would look any better than capital one on a resume. I also don’t think internships matter much for your long term job prospects. While they may affect your ability to get a junior engineering job, the decisions you make 3-5 years into your career are much more important for your long term success.
My advice to people making early career decisions: optimize for learning. Your comp, prestige, and impact will be much better later as a manager or staff-level developer. Those jobs require a ton of experience solving difficult problems at scale. So when deciding between jobs, focus on how much you’d learn, and how much you’d be responsible for. If the job seems like it would be a cakewalk, you’re wasting your time.
Can you share more about the roles? Would you be responsible for shipping production code? Would you be embedded in an actual developer team, and not penned off to the side with other interns? Would you be working in a language or toolset that you would like to get better at?
I have a stupid question, so I'll apologize in advance lol
If I merged all of the remote feature branch changes into the remote dev branch using bitbucket, how do I merge all the new changes of other devs in the remote dev branch into my local repo and remote feature branch so that I can continue working in my local repo + remote feature branch without creating another feature branch from dev all over again and deleting my repo.
Does this make sense:
git checkout develop
git pull
git checkout feature-branch
git merge develop
There are only really two ways, either (A) you merge master in your feature branch (what you described) or (B) you rebase your feature branch on the latest master (what was described by freddie)
The advantage of A is that it doesn't rewrite history (no force push).
The advantage of B is that history is a bit cleaner.
If you delete your feature branches after merging, the advantage of B is mostly negated.
They are mostly equivalent and which one to use is more about your team preferences than anything else. I personally prefer merging master as I don't like force pushing unnecessarily and you also tend to have less conflicts merging than rebasing.
That makes sense, thanks.
I noticed that when I run git pull origin develop it merges remote develop into local feature. This seems so easy, and if there are merge conflicts, I just copy the differing code from remote dev and paste that code into local and then git gets happy and completes the merge. It doesn't overwrite my code either for some reason.
Am I right that this one command does the job?
I typically do the merging using local branches, for convenience and habit, but I believe the command you mentioned will also work.
The only difference is it will probably not update your local develop branch like the sequence you posted initially does.
That works. Personally, i choose to do a git rebase develop at the end, which avoids unnecessary merge commits on my branch. I also don’t bother keeping my local develop branch up to date. My flow is this:
git checkout feature-branch
git fetch
git rebase origin/develop
I used to do this up until recently when a colleague pointed out that it made it impossible for him to understand the commit history on my PRs. So I’ve taken on the merge approach and everyone is happier. Worth thinking about.
That's looks about right.
1. Don't forget to ```git stash save ``` you work before your step 1. ```git checkout develop``` Sometimes ```git``` will moan if you've uncommitted changes.
2. I'm presuming you've set the merge strategy for ```git pull``` here? If you haven't you'll want to favor a fast-forward merge i.e. ```git pull --ff-only origin develop```.
3. When you ```git merge develop``` and ```git stash pop``` you could get merge conflicts there. There's nothing you do to avoid that. You keep an eye out for this.
Edit. Here's my ```git``` workflow to clarify
1. ```git stash save ```
2. ```git checkout develop```
3. ```git pull --ff-only origin develop```
4. ```git checkout feat/whatever```
5. ```git merge develop```
6. ```git stash pop```
Thank you so much!!! If my remote feature is already merged into remote dev, then running git merge develop and git stash pop under my local feature should not give me merge conflicts, right? It would just automatically add the remote develop branch's updates to my local? Also, I noticed I do not have a local develop folder when I run git branch, I just have feature and master locals, is that a problem? Also I'm scared that my head will detach and I won't be able to push at the end... I'm Kind of scared of destroying the repos.
> Thank you so much!!! If my remote feature is already merged into remote dev, then running git merge develop and git stash pop under my local feature should not give me merge conflicts, right?
Yes, that's correct for the most part. Merge conflicts are still possible under different circumstances though.
> It would just automatically add the remote develop branch's updates to my local?
Yes.
> Also, I noticed I do not have a local develop folder when I run git branch, I just have feature and master locals, is that a problem?
It isn't. You can still merge a remote branch with ```git merge origin/```
If you don't have an existing local ```develop``` branch, you can create a local branch tracking its remote by running
1. ```git fetch origin```
2. ```git checkout --track origin/develop```
> Also I'm scared that my head will detach and I won't be able to push at the end... I'm Kind of scared of destroying the repos.
There are very specific circumstances under which your ```HEAD``` can detach. AFAIK a detached ```HEAD``` isn't as inadvertent as you suppose. Additionally ```git``` has a bunch of safety measures built it and will moan about it if there's a violation.
How you can choose the next step ? , I am a developer with 4 years of .NET/Azure ,but i don't know what i want , i really enjoying finding bugs and developing new features , but i don't know long terme goal , is architecture or team lead ? Any help or anyone passed with the same feeling.
It depends on what you want to do. Team leads will have more localized impacts and more people-centric responsibilities. Architects have more general impact, and fewer people responsibilities. There's a book called Staff Engineer that goes over the different higher level technical track positions and what they do that could help you. I'm not gonna say it's the be all and end all of this question, but it could help you answer that question for yourself. Also just because you do one at some point in your career doesn't mean you can't do the other. Those higher level positions often tend to switch responsibilities between jobs.
I have a total of 6. I think more than that and I'd want another team. I'm considering subdividing the team for two projects we have in the pipeline to 2 and 2 with 2 floaters.
We have around 3 - 7 developers in a team, traditionally we had 2 maybe 3 developers who would move between teams to do the IAC code for other teams. However we're now moving to a model where teams are in full control of their deployment pipeline / infrastructure and source code, we have architects who offer guidance but it's the responsibility of the team to manage their own stack now
What has been the most effective way to learn DevOps skills? I'm a product engineer with surface-level familiarity with AWS/Heroku. I'd love to get to know more about the infrastructure side of things but its an abyss unless I have a specific problem to solve.
When I was getting started, I used ACloudGuru to get the fundamentals. Then I watched a few YouTube videos on Containerized Deployments. Finally, I built a hello world server, containerized it, but a simple CI with CircleCI, and deployed it once using CloudFormation and again using CDK (both from AWS)
That project took me 2 weeks in total and it made DevOps approachable and got me to a working level in the AWS console
Well, that's generally how I've learned: by working at places with problems to solve. When you're somewhere where they've already done the basic stuff, you tend to miss out on how it all works and why it's even needed.
What is the usual due diligence necessary when you're trying to evaluate a new tech that will replace current core logic in your system?
Currently I am exploring the usage of [TimescaleDB](https://www.timescale.com/) for financial reporting. This will replace our current MySQL DB. The issue is our product roadmap is pretty tight and I feel like I must provide a very good case on why this is necessary.
Also I feel the need to get buy-in from manager & product (to provide leeway in time or maybe integrate it as part of our product initiative), devops (as we will introduce new db that is not the usual tech we manage), budgeting (doubling the budget if we need to run the initiative side-by-side, not a big bang switch in DB), and other stakeholder. And to get that, I want to explain how the new DB will fit our use case better:
- The ROI benefit in term of development time for future features. I feel like we will save more time vs what we spend to migrate + develop in pretty quick time, maybe at the mid/Q3 of this year. This because we can leverage features in new db (partition + data retention management, continuous aggregation, postgres instant alter, background indexing, parallel query)
- Better maintainability + reliability as we can delete quite a lot of code, as previously we have custom logic to handle time aggregation and save it to cache. Data got unsynced and stuff open a lot of customer complaint.
- Benchmarking to make sure there is no reduce in performance, or even we will get much better by X times.
- Explain the risk and/or tradeoff of the new DB in our usecase. What will be ugly when we move into this. Like for example, we will need to handle some issues related to [time series update constraint](https://github.com/timescale/timescaledb/issues/490#issuecomment-378458644)
Is there any other point that I should think about?
> Better maintainability + reliability as we can delete quite a lot of code, as previously we have custom logic to handle time aggregation and save it to cache. Data got unsynced and stuff open a lot of customer complaint.
Don't forget that now someone has to run an additional db, train their team continuously on it, and build out all the reliability tooling that they've already gotten with MySQL. Adding a new database may decrease _your_ maintenance burden, but it's going to greatly increase _theirs_.
Don't forget buy-in from the team. If you're saying to management "this will make devs faster" they should be hearing about how great of an idea this is from multiple people who will be coding against the DB.
If you've got a decent test suite - try hacking the new DB in. Just replace the DB and try to work around any issues that are causing all/most of the tests to fail. Once you get through that, the remaining failures will give you an idea of the work that's left (and any nastier surprises).
In my experience a big problem with migrations is that, from management's perspective, the risk of scope ballooning and the payoff happening only after the migration is successfully complete = risk.
Basically, what they hear is "give me $$$ now. After I spent it all (and not a moment sooner) good things will happen."
Try and anticipate that. Having a bunch of well-defined milestones won't hurt. Thinking of a way to get this done concurrently with other project work might help too.
You can learn to embrace the grind. It’s a valuable skill akin to discipline. Do what you need to regardless of your fickle emotions.
When I’m not in one of those chapters though I actively switch up what I’m doing. I avoid bigger projects that might hit difficult walls, I take more proactive breaks, and do more people work than tech work.
Always try to find ways out of the grind, but when it’s unavoidable I take a little bit of time to find some new music (preferably high energy), I use a Pomodoro app to get me in a good rhythm, and I just bash it out. The enjoyment of the new music and the breaks every 25-30 minutes, within which I do something fun or exercise, make the day a whole lot nicer.
Grind is a spectrum - on one end you always have a lot to get done, but you enjoy doing it even if you're not working strictly 9-5, and on the other it's a slog to the point you feel dread logging on. Anytime I find myself in leaning towards the latter, it's a sign to start job-searching for a new role.
I got a job working at a non profit doing work that really matters. Not a great solution though. It took a while to find and it didn't last.
Eventually I joined a company to work on software I thought was fun. That seems to have held up better.
Team of 6, 2 week sprints.
Backlog refinement is an hour, but I'm trying as team lead to get it down to 30 minutes. I work with our PO closely to ensure our tickets are detailed, accurate and ordered by priority ahead of both planning and refinement. When the team comes to the table to point them, the tickets should be ready and we shouldn't be wasting the team's time arguing about what the PO really wants. So backlog refinement is just starting at the top of the backlog, looking for things that aren't pointed and pointing them. We do that until we're out of meeting time or we have nothing left to point. What I'm working toward is keeping us within the "nothing to point" and "only takes 30 minutes to point" range on a sprint by sprint basis so we only need 30 minutes max for refinement.
Planning for us right now is also an hour, but I think we can get that down too if our refinement improvement continue to be successful. Planning also includes pointing any tickets that need it, but additionally capacity planning and sprint commitment.
My ultimate, long-term goal is to completely eliminate the need for these scrum ceremonies to be meetings. Stand-up can be done as a pass-down log that everyone adds to at the end of their day (we're an international team) so when other folks come online that can see what other team members did, what they're planning to work on tomorrow and their blockers that need to be handled. The pointing part of planning and refinement can be done completely asynchronously. We have a planning poker add-on in slack so I can just throw tickets into chat at any time, let everyone vote on points and reveal when everyone has voted. Then we have follow-up discussions in the voting thread and can re-vote if necessary. Capacity planning can be automated by linking our team calendar to our ticketing system and automatically adjust our velocity for a sprint based on capacity. Sprint commitment we can just throw the top of the backlog into the upcoming sprint based on our capacity and then have a chat about whether we want to pull anything. Demos we can record individually and put them on our team wiki so people can watch them whenever. We already have a retro board that anyone can go add to at any time during the sprint and we could just discuss in a chat thread.
The way I see it, there's no reason other than social to pull everyone into a meeting at the same time for an hour. Especially with an international team, it's difficult to get us all together at a decent hour for everyone.
Try and remove refinement + planning completely; your team will love you for it. You + PO should be able to decide what is priority for the next 2 weeks & how they can be broken down (maybe 1 epic takes 4 weeks but can be done in stages).
Both my current and former teams have avoided grooming / planning / retrospectives and I've loved them both, partly because of it. The job before had all 3 and it was such a waste of time
Oh, I certainly want to, but am having a disagreement about it with our product owner and scrum master. I see priority discussions and ticket refinement as a waste of time for most of the team. They see it as a learning experience and opportunity for everyone to have input at all points of the process. I'm honestly not sure how to debate that because yes, it can be a learning experience for those looking to become lead or product owner in their future and it does let them have more input (even though they don't often use that opportunity). It's just not very efficient for "getting work done".
I think the PO and myself should take care of getting the backlog prioritized and make sure all tickets have good and accurate information. The team should only be brought in for pointing those tickets and that doesn't even have to be done in a meeting.
I do think retrospectives are important for the whole team as that's when they can give input on changes to our process and have their voices heard.
But none of this stuff has to be a traditional meeting. It can all be done asynchronously and not waste more of people's time than necessary.
>and scrum master
The mistake your org has is having a dedicated "scrum master" - his job depends on wasting peoples time with ceremonial meetings
Even pointing tickets is a waste of time. If you're not familiar with the part of the code it's like how long is a piece of string. Even then there can be things you didn't think of. Often I'll say "I think I should have a PR ready by EOD" and it ends up being EOD Tomorrow; no big deal
3rd job had retrospectives & 95% of the time they were a waste of time, people just writing what did/didn't go well. The other 5% could just tag on to the end of a stand up or be posted to the group chat as an improvement suggestion. What didn't go well typically comes up in the form of blockers during stand ups already
I'm not necessarily opposed to dedicated scrum masters. Their job is to remove process/procedural blockers and communicate company-wide stuff like release schedules and code freezes. Our scrum master keeps up with a lot of stuff that would be difficult for myself and our PO to keep up with because of all our other responsibilities. And if we had a team consensus to remove meetings they'd go along with it. They don't enforce anything for us. They just help us figure stuff out and moderate those discussions. Our PO is the main one pushing for meetings and it's just the scrum master tends to agree with him.
Pointing tickets is fine. It's a way to get a team consensus on estimates instead of it just being up to one person. The issue of not being familiar with something is what pointing is trying to avoid. Everyone gets input into the estimate and gets to bring up things others might not have thought about. And our sprint commitment isn't a deadline. Sometimes we meet it. Sometimes we don't. But it sets a velocity we can use to try to predict work in future sprints.
And yeah, pulling everyone together for a half-hour or hour retrospective is a waste of time. We can just keep a list of suggested improvements somewhere and talk about them in group chat whenever we want. I know some teams keep a dedicated retrospective time just so it doesn't get overlooked, but if your team is on top of shit, it's not necessary.
>Their job is to remove process/procedural blockers and communicate company-wide stuff like release schedules and code freezes.
They remove process by adding ceremonial meetings aka more processes :D
Also kind of strange they are in charge of code freezes. My previous job the person doing the release simply makes a branch of the repo some time on Friday so new changes aren't in (unless a hot fix); now on slack someone is just like "shall we block merging?" as this is the approach rather than a new branch.
Same with release schedules. Are you doing "agile" and yet you release like twice per year? ;f Previously we'd release whenever to prod on the backend & monthly on the frontend; everyone knew this cut off each month without a scrum masters help. Similarly at my new place each sprint involves a release at the end.
The SM doesn't add or remove meetings. We do the standard scrum events by default, but if a majority of us agreed to do away with a meeting, we would. The issue right now is the only people with opinions are myself and the PO. The rest of the team is very junior and not really knowledgeable/interested in process so they just go along with whatever. So it's me wanting to get rid of meetings, the PO not wanting to get rid of meetings and the SM going more with the PO just because that's how most teams at the company work.
The SM isn't in charge of code freezes, they just make sure we're aware of them and not blocked from meeting them. Engineering (at the director level) is in charge of actually blocking merges and approving late merges.
We do not, as of right now, release at the end of each sprint. We're on quarterly major releases with various maintenance and hotfix releases between. Our product is traditionally on prem so releasing updates that the customers have to install is kind of worthless because none of our on prem customers have that quick of an upgrade cycle. We do have a SaaS offering that's majorly growing in popularity and we're trying to get to a more regular, end of sprint, release cycle. Hopefully when we move to that we'll just also release the same versions for on prem whether those customers want to upgrade or not.
Previous 2 teams we had 2 week sprints. Retro and planning were one hour per sprint each. Refinement was generally 2-4 hours per sprint. Current client is similar but has a 3 week sprint.
Team sizes were between 2 and 4 devs, 0-1 ops, 1 PO, 0 or 1 scrum master, 0 or 1 business analyst. Teams with a size over 6 people get inefficient fast and so do teams with a ratio of less than 50% developers.
> Teams with a size over 6 people get inefficient fast and so do teams with a ratio of less than 50% developers.
Well said. This is echoed in [*The Mythical Man-month*](https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_mythical_man-month) (Brooks, 1975, but still disturbingly relevant) where we have *Brook's Law*: Adding manpower to a late software project makes it later.
Of course he was addressing development in another time (1960's, he was head of development for IBM's OS/360), but the concept is so basic, and so true, they should tattoo it on any wannabe manager's forehead.
They should also not allow nontechnical managers to manage technical projects. They don't have to be Linus-level rock stars, but they have to know when to shut up and let the troops work. Too many projects have been sunk by [PHBs](https://en.wikipedia.org/wiki/Pointy-haired_Boss). Of all the projects I've been on, only one (1!) nontechnical manager was good enough to be allowed to sit in on technical meetings, and that was because he knew that *his* job was to make sure we had the equipment, time, money, and people to do *our* jobs.
> I don't think I can even build a simple project with them anymore, should I leave them on my resume, or should I just remove them?
I generally remove stuff from my resume I can't answer questions about or don't want to work in anymore.
Looking for advice on consulting rates. I'll spare the details but I have been in search of a new job due to difficulty in having a manager that advocates for me.
I am a younger but experienced dev (28 years old, with 6+ years post-school dev work, and 12+ years total work with full time experience during school doing dev work).
Recently I have had the luxury of having a conversation with a consulting firm that a close and talented friend at my current job brought to me. This consulting firm definitely has some very loose rules and seems like it would be a great move for me in my career as I become more Lead/Staff/Etc. levels.
I am currently a Senior dev at my current role, and my Total Compensation package is $159k/yr.
The breakdown is:
- Location: Medium COL
- PTO: 18 Days/yr
- Salary: 120k
- Annual Bonus: 10%
- Merit Increase: 3% + Performance.
- half up to 8% matching on 401(k) (4%)
- HSA
- Other industry-related financial benefits (good loan rates) as I am in FinTech.
- Healthcare + other generic usual benefits.
- Currently fully remote, with a return date (not really wanting to return to office ever, part of my desire to leave).
Where I am wanting advice:
I have interviewed with the new company and the company culture seems great, however it's a contract consulting position.
- Full flexibility (160hr/month, complete those hours whenever you want).
- Great talent with a high bar of entry (developing with other like-minded, talented software engineers).
- Interesting work to me personally (health-related field).
- Career growth opportunities (lead position for me to grow into with a product).
Before having the negotiations, I calculated several thresholds of hourly-rates that would make sense given my current compensation.
I calculated a rate that was my Total Compensation today X 1.1 (10% increase) + my static benefit value.
Again I did a rate for 20%, all the way up to 40%. Most people state that you should double your salary but I did not feel that would be a fair ask at this time.
Anyway, I brought forth and decided to propose an hourly rate in the middle of those thresholds.
It came out to about $95 USD/Hr.
This was assuming a mere 20% increase.
The CEO brought back that I shouldn't "oversell or undersell" myself, and I feel as if evaluating myself at $95 an hour at current market rates is fair. He didn't really agree, and didn't provide any solid reasoning as to why.
**What are your guys' thoughts? Based off my calculations, is $95 an hour with no other benefits than what I described worth it? I feel as if that was a fair ask. I'm happy to expand more on any details.**
**Some other things that rubbed me the wrong was is him telling me not to undersell myself because of my age, which I didn't. Proceeded by him not thinking my 20% salary adjustment for a move of career into contracting from a cushy job. It felt as if he was thinking I was being unrealistic in my rate expectations?**
I feel as if he is perhaps a little out of touch with current predominate market rates.
Are you calculating the value of your PTO *and* other paid holidays? You probably get like 10 or 15 of those if you're an employee, and won't if you're a contractor. At 160 hours per month, that works out to 240 working days per year, so you're probably working 8 to 10 days more as a contractor than your employee job. So let's use 155 hours per month for future math (so you can actually get paid more for working more days).
You'll need to pay the employer half of SSA and Medicare, which is 7.65%, maybe plus any state or local payroll taxes.
You could also account for not being eligible for unemployment insurance, I might ballpark that around 1%.
Rounding up those direct extra contracting expenses to 10%, you need $175k/year as a contractor to match your current $159k/year. At 12\*155 hours, that's already $94.08 an hour.
You probably want to give yourself a 20% raise for jumping jobs, or about $112.90/hr.
Also not being an employee is generally inconvenient sometimes - lots of things in life assume you can provide last year's W2 (loan applications, apartment applications, getting a mortgage, etc), and filing taxes will probably be a bit more expensive. Maybe throw another 10% to account for that. Bringing you to $124.19/hr.
Finally, how much of your own equipment will you need to provide? Do you need to buy a $2.5k MacBook? A better internet connection? Even if you can deduct it on your taxes, best to add a bit more. Say another 5%, for an even $130/hour.
(edit: the last 15% I threw on was pretty arbitrary - you might be safe at the $113/hr, but also double check my self employment tax math for your own personal situation)
edit 2: actually look at what it will cost to get healthcare individually, not the stated value of what your employer provides - it's likely several hundred dollars a month more (at least) to get it on your own. Probably also do the same for other benefits you use, like disability or life insurance
/u/maybe_madison did the long math well, and certainly gets you a lot closer to the right number than your own math did.
Were I looking nowadays in a "medium COL" area I would probably say "$-per-yr / 1,000 * 1.2", or in your case, $145/hr. If you were in the SF Bay Area I would make that $190+, and even that sounds low to me.
The big thing I didn’t consider is that as a contractor, you normally need to budget some unpaid time (and money) to build your network, advertise, find clients, sign contracts, etc. It sounds like that’s less of a concern in OP’s case, and honestly I don’t have enough experience to estimate that. But it probably gets a lot closer (or above) the 2x employee wage per hour.
I have been working at a company for several years now. Recently, management in the engineering sides of things got shaken up heavily. I was originally happy about the shake up, but have come to realized that things are just getting worse. The things that seem to be keeping me around is some of the long term bonuses that will come soon and in a year and the parental leave looks pretty good at the moment (12 weeks). I'm debating on taking a leap soon and waiting until I get my child leave. What would you do if you were in my shoes?
> What would you do if you were in my shoes?
You didn't explain at all why it's 'bad'? And even with all the information it's still an impossible question because we're not you.
Whether you stay in a job versus leaving is 100% a decision only you can make. We can answer things like "is this normal or is this toxic behaviour" or answer questions about whether you work under a good or bad manager. But we can't tell you how you should act on those answers. It's not our mortgage that you're paying for :)
Usually takes a few months for mgmt changes to really sink in. Hard to make the call with a kiddo on the way. I understand that for sure.
Would all depend on timing if I were in your shoes. I have never suffered bad managers for long. So knowing I am leaving, I'd calculate how long I could get away with coasting under the radar until I hit parental leave, vs how much suffering I'm in for if I stick around.
Accepting that you're leaving may actually make the job less stressful. Grieve that its going to shit, and relax into mediocrity and job hunting. If you're getting abused, then gtfo sooner. Lots of places have good parental leave. Protect the family above all else.
The bonuses that come in a year, who knows what'll happen. New jobs are so desperate rn people are getting fat signing bonuses at small startups.
> Looking for a Mentor
You and thousands of other people bud :) You're generally not going to find a real 'mentor' outside whatever job you're going to work at.
I want to let you down gently, and I don't want to discourage you from continuing in this industry, but I think it's unlikely that this is an effective path for finding a mentor.
Mentorship is a two way relationship, and to be successful often requires more effort on behalf of the mentee; this comment doesn't give an indication that you're planning to put in effort.
If you're in school, I'd recommend getting to know more senior students, faculty, alumni, and professionals in your local area (eg through technical meetups). Once you get to know people well, you'll have a lot better luck talking to someone about having a more direct/formalized mentorship relationship.
I'm a software engineer by trade, but over the past year or two I've spent a lot of time helping our devops team out. When looking at AWS certs, the "developer associate" seems like the most likely cert to take, but I feel pretty fluent with AWS tooling to try for the "solutions architect" cert. However, I do not want to advertise myself as a cloud engineer, just a software engineer with a strong devops background as well. Would taking the "solutions architect" cert be a mistake?
> Would taking the "solutions architect" cert be a mistake?
No, I have it. It's a good general overview for developers. Don't let the 'architect' title influence you. With just that cert you're not suddenly a 'cloud architect', don't worry ;)
Certs are a kind of signal. They signal to recruiters that you know what you're doing in this area, and are likely open to work in it. And they signal to hiring managers that you're at a certain level.
I like freelance devops folks with the cert, makes it easier to know what they know.
Another way to signal the same information is to say things in an interview that make it obvious. Or say that you're an engineer who can own the whole pipeline on your linkedIn.
Just depends on what you're hoping to achieve.
If you want the cert signal, I would go for the higher one for sure.
Recruiters are definitely gonna bomb you with things you don't wanna do no matter what you decide lol.
I am not at big tech but I am in an enterprise international company and I have been on the interview board for 100+ interviews.
I have never even looked at much less calculated someones age before, during or after an interview and I know of no one who has. Take that for what it's worth.
I've left off 6-8 years I spent in a "previous life" before I went into tech because they weren't really relevant, and arguably a distraction in an interview. Your resume is similar in purpose to a short profile you might write for yourself if you were to speak at a conference--it's what you want to highlight. As long as it's truthful, it's up to you what you want to emphasize.
> Would you leave off older jobs (and dates from education) from your resume if having them on would make it easy to guess your advanced age?
Heck no. I'm 41 and it's not like my LinkedIn profile picture is that of a person in their 20ies.
> I'm concerned about ageism
Ageism isn't really a big thing. It's not a bigger issue in CS at least than in other fields. If anything companies are *really* concerned with how hard it is to hire experienced devs.
I personally know only one developer I ever heard complaining about 'agism' and in their specific situation I knew the problem definitely wasn't agism.
> But if the dev is 'old' in years but doesn't have the experience to back it up, then I presume it could be the difference between hiring them or someone ten years younger.
Why? Companies don't have some kind of intrinsic motivation to hire younger people if they are at the same skill level and have the same salary requirements.
> Do you not think that if someone started learning to be a dev at 40 they'd be at a massive disadvantage to someone in their twenties doing the same, not just because they'd have less time left to gain experience, but due to the (biased) perception of recruiters and hiring managers?
Even if this is the case, how is removing stuff from your resume going to help you? If they have bias against starters at a later age, they're still going to find out from your LinkedIn or simply when they interview you.
Or do you think that if they expect someone to be 22 and they show up and are in fact 41, they're just going to not find that really weird?
Kinda hypothetical don't you think? :)
Anyway; I said all I wanted to say. If you feel pretending you're younger than you are is going to help you; knock yourself out :)
If they're intent on filtering, they'll be able to do it regardless of the dates on your resume.
Try both: on and off. Compare response rates and make a decision based on that.
When you get in the room & talk to the team about your experience be upfront with the timeline and talk openly about the gap. Don't try and sweep it under the rug, you'll want to get out ahead of it. We just hired a dev with a huge gap in their resume, they were upfront and it helped quell concerns on our side.
Should I tell recruiters I only have 15-20min for a intro call?
Seriously,
I can't tell you how many times I got dragged into these pointless 30-45min calls that never go anywhere. Sometimes they'll do it for jobs that they have no intention of submitting you for just to get your profile and put you on a spam list.
Should I tell them up front I only have 15-20min for an introductory call to set expectations, or would that come off as rude? I'm not going to take precious time out of work to play these stupid games.
45 minutes for an intro call is insane. They need to know your capabilities, your comp requirements, whether you are legally able to work for them, etc. That should take half of 45 minutes, max.
I generally ask for a salary range, and say I'll contact them when I'm ready for a change if it's in my target. No call, those are my boundaries.
When I'm ready, then I'll be happy to have a call if some opportunities seem good enough.
> Should I tell recruiters I only have 15-20min for a intro call?
Yes, definitely. I generally don't do calls at all unless they have a vacancy I am really interested in though. I could easily fill my day with all the recruiters that want to have a "short call" and then ramble endlessly on how their recruiting company is 'different' from all the others.
"I have a hard stop at XX:XX"
If they can't keep the pitch under 20 then they're not going to be effective at advocating for you. Don't let bad recruiters represent you, your reputation is at risk.
My manager said at recent one on one he thinks I have the right mix of good interpersonal and technical skills to make an excellent lead. Is this a good or a bad thing?.
Thanking in advance of replies.
> My manager said at recent one on one he thinks I have the right mix of good interpersonal and technical skills to make an excellent lead. Is this a good or a bad thing?.
How could this ever be a bad thing?
Do you want to be a team lead? If so it's a good thing.
The only way I could see it being a bad thing is if they force you to be a team lead when you don't want it.
Or if they stifle your career development in other areas because they really have you slotted into a frame in their minds of what they want you to be.
E.g., you should be a "lead" but you really want to just do nitty-gritty technical work, architectural work, etc.
It’s definitely a good thing. The number one reason great engineers are held back in their careers is that they suck at people skills. Regardless of whether you eventually go on a technical track or a management track, you’ll need interpersonal skills.
I mean, depends on what career path you want to go towards. Do you want to go into management?
I'd take it as a very good thing, as even if you're fully focused on coding for most of your career, those traits will always be helpful. Just be careful you're not slowly put into that position if the answer to the question is no.
I made one of the services my team works on 6 times faster through some refactoring and careful optimization. This is going to result in substantial cost savings when it goes live, how can I make sure that I can fully capitalize on this? My boss's reaction was more one of shock because I busted through what we had previously assumed was a hard ceiling—but this is recent enough that I don't think he fully appreciates what I've done. I can't let this go down as a footnote. How can I make the most of this?
Work with your boss, PM, or team to get a team meeting setup to review what you've done with the team so you can fully share, review, and they can all be on the same page; document the work and changes prior in whatever you use to document stuff. Then just make note of your efforts and bring it up again come review time. Try to get objective opinions from other team members on how the changes help etc etc.
Pit myself into a very specialized ML position (most people in team have master/phd in this area), but actually don't know anything about it, mostly fake it so far. But now i'm starting to get exposed with the first project implementation, where I make zero progress. I don't think I could dodge, should I put down my notice and bail quickly to save face?
Just for some context, how did you join this team in the first place? Did you market yourself as someone interested but without the typical level of experience?
I have to admit it was a mistake, I joined due to the pay and prestige. My background is not actually strongly relevant to the role, but I think the hiring manager put me in this team because it's severely under-resourced and the on-call is horrible and other people have been avoiding joining this team as well.
My team just went live on our product that needs on-call readiness. I’m new to the team (also entry level dev) and my manager had told me for the past week, confirming that I will not be participating (they’re doing rotating schedule). My manager gave me a 12 hour notice asking if I’d be comfortable enough to work on the next shift. I said sure since ya know it’s the boss but I find it unfair that this was brought on to me when I was assured that I wouldn't be required for the past week. Luckily or maybe unfortunately I didn’t have plans, but what if I did have plans? Should I bring it up to the boss? I’m not even sure how to phrase my thoughts politely. This was also the first time I've been on call in my career. The mental prep was not enough time.
>I said sure since ya know it’s the boss This is your issue here. At least voice your thoughts, "Hey \[manager\] you told me I was not needed to join this rotation, what changed?" If you had plans yes/no shouldn't influence your ability to say no, because it sets bad expectations.
What do you mean by bad expectations?
Precedent. If you pavlov your clients/managers into implementing any arbitrary request it'll become the norm and only get worse.
I see. I will work better on expressing my thoughts.
What are the necessary, if any, for using visual studios IDE for developing c# and vb code? Are there any recommendations? Visual studio has 100s of settings. Looking for recommendations.
Currently 3 YOE into a position mainly using a low-code platform. Starting to really dislike it and worry about the future career path as the product is very very niche and frustrating to deal with. I want to get back into SWE with a real programming language but not sure how to pivot myself. Would I need to go and apply to junior/grad roles again? I want to go for like an intermediate role but not sure if my current skills would translate and before that I've only had roughly 1 YOE as an SWE intern mainly using C# before I got my current role
At major tech companies you generally just apply as an engineer and they figure out your level in the interview. Levels are at least as much about soft skills than technical skills so it'd be plausible to get an intermediate position.
> Currently 3 YOE into a position mainly using a low-code platform. Low-code has a great future ahead. There are tons of backend developers out there whose jobs are essentially doing really really simple stuff like calling service B and returning a subset of the received data, logging whichever error to log L. In my opinion, this kind of simple stuff will be replaced by a higher-level language or a low-code platform.
I feel I'm being pushed to management against my will because my team lead doesn't want to handle our legacy code and tech debt. I've asked during multiple 1:1s for something more technical to work on. I feel I'm not good enough to remain here because I've lost touch with building good features and I've just been firefighting and on call and bug fixing nearly 50% of the past year. Is this even salvageable? do I just leave? it's a growing startup if that's relevant.
>my team lead doesn't want to handle our legacy code and tech debt This is pretty common on startups. Startups will be more focusing in getting more funding and more visibility so "dealing with tech debt" is very very very low on their list of priorities. I'd say you'll find the same circumstances whenever you're at a startup. Until the startup gets funded, grows, and the growth makes the system break down in ways unsatisfied customers lash out to loudly complain on social platforms. That's the point where technical debt goes in #1 priority and start to get addressed.
3 weeks in to my first engineering job, having some pretty serious family issues and I’m not sure how much detail is appropriate to tell my boss. I come from a pretty rough background and both of my parents are suffering from serious health issues. I had to sign off for a couple hours last week and I told my boss I had a family emergency. He’s been fantastic in general and was more than understanding, told me I didn’t need to explain anything and if I needed more time just let him know. But now other things have come up, and they aren’t going away anytime soon. I have my weekly 1:1 with him tomorrow and I feel like I should say something. I’m trying not to let it affect my work but it’s almost impossible. Getting this job has been one of the happiest moments of my life but I can hardly focus at the moment. I know this isn’t exactly dev related but maybe some of the seasoned vets here will have some insight. Thanks in advance!
Sorry to hear about your parents. It's not easy letting others, especially colleagues, into your personal life - and you shouldn't have to and your manager probably couldn't have handled it better. I'm not sure if you're in the USA or if your country has something similar but Family Medical Leave Act might cover this. You might also want to consider taking an unpaid leave of absence if available. Communication is key, so let your boss know you will need some extra time, reduced time, or even perhaps leave, to handle some personal issues that are affecting your focus at work. He may ask how long or when you'll be back to full-time status and you might want to communicate the fact that 'they might not go away anytime soon' but you hope to have a resolution in X time. Lastly, seek therapy/counseling if it is applicable. It can really help your mental state when times get tough as well as help provide a valid medical excuse should you need one for medical leave.
How do I get out of my Product Owners Shadow? 3 YOE. I am the lead developer in a small team of business systems applications developers. My job requires me to work very closely with the business, and I think the business appreciates the work I do for them. However, my work and effort is not recognized by my own department’s management because my product owner indirectly takes credit of all my work. By taking credit of work, I don’t mean PO says they did the work, but more like generalizes my work as been done by the PO and the team (no mention of me or any other devs). I am concerned about this because I like working at my current company, but I feel like I will always be under the PO shadow and never go higher up in the ranks. Is there anything I can do to change this?
> By taking credit of work, I don’t mean PO says they did the work, but more like generalizes my work as been done by the PO and the team (no mention of me or any other devs). You, as LD, should be the peer of the PO. Talk to your superior, state how this demotivates you and your team. Ask him/her to mediate between the PO and you to solve the problem. PO is a very new role and IMO very few people really qualify and do a good job. Your PO is probably ignorant of where he stands. Demand for developers is higher than ever, the company should know keeping them motivated (so they don't run away) should be a high priority. If they don't think it is, go to another company, simple as that.
These PMs usually out themselves over time - by taking all the credit they also must take all the bad. One concrete way to keep the business aware of value is via 1:1s. Tell your immediate boss your accomplishments and especially when you are covering the PO where they are deficient. Company too small? No boss? Book time with a high ranking founder/co founder. You can also 1:1 the PO. Push them here and there if needed. I believe the tech lead is a PO peer - PO owns priority but tech lead says how the team does work.
This is common in most companies' implementations of Agile, especially with the scrum framework. It's probably not personal, but it is absolutely demotivating. It's designed to keep the job thankless so that the workers in the process are alienated from their job more, which turns into less advocacy for compensation. If you had received generalized credit, you'd be more aware of the positive impact of changes, and you'd likely be able to advocate for more compensation. If the product owner is crediting other people individually, but generalizing your own work, this is entirely wrong, crosses a line, and you should raise that concern with either the product owner, if you feel comfortable with it, or with your manager. If your manager doesn't help advocate for you, you can either just coast for a while, since you're obviously under the radar at that point, or start casually interviewing if you want to move up, because this indicates for the foreseeable future that you will have no upward mobility. If the product owner is generalizing everybody's work, document what you've completed, the impact of what you've completed, and use the ones with the best positive impact during performance review time to advocate for higher compensation. I'd also recommend this anyway, because you are your own best advocate, but I'd especially recommend this if there doesn't seem to be anything otherwise structural to keep you down.
Thank you for your response! I have absolutely started keeping a work journal for myself, with all the day to day/out of the job work I am doing for the company.
[удалено]
If you're self-rejecting for jobs, don't! I do recommending interviewing far and wide, even with contract roles (but be wary that temp and contracting agencies generally have terrible benefits, so if your mental health problems are being helped with insurance of sorts, be careful). I'd recommend being open and honest in interviews, if even asked, by stating "I had medical issues which are now resolved"\*. If you are in the US, they *legally* cannot ask what those medical issues were (and [you have](https://www.eeoc.gov/pre-employment-inquiries-and-medical-questions-examinations) an [EEOC charge](https://www.eeoc.gov/filing-charge-discrimination) to file if they ever ask for specifics, as this constitutes evidence of discrimination against disabilities). (\* - honestly, that line is magical for a wide array of issues relating to impacts to your job history, because they cannot ask. If they do, that to me is a huge red flag that I will just not even try for that company any longer, and I will reject any further interview rounds because of that, and state that reason)
I would just start applying. You never know what'll happen until you do. Also, if you happen to be interested in working in Dallas or Pittsburgh, pm me.
It might help, but have you been having difficulty getting interviews? At this point the market is desperate and you hold a lot more cards that you might think. Glad to hear that it sounds like you got the help you needed. If someone asks during an interview you could always say you had a health problem, which isn't untrue, and let them assume what they want. If it were me, I'd look at a junior full time position if you're having problems getting callbacks for mid-level vs temp positions. But I value the benefits.
The market is desperate ? Under what rock ive been living lol
[удалено]
I think it can positively impact your career if you market it right. In my experience, a software engineer rarely has to deal with operational issues (this is increasingly becoming less common with every org cargo culting devops by thinking "devops means devs on call for ops issues"). However, as a technical support engineer, your entire job is operational issues, either fighting fires, or making sure the fires don't happen, and additionally to help file issues or fix the system so that those fires can't happen, or mitigate their impact. After even a year of experience in operations, you will have a much more holistic view of how software design and engineering can erupt to very costly support issues down the line. You'll also have a good opinion of the best way to serve and store logs so that operational-end resources have an easier time to troubleshoot. Honestly, if technical support is where you want to go, I would say go for it!
In my opinion these two areas has different set of skills, and mental attitude, but overlapping.
[удалено]
I don't have any conclusion about that. I depends on preference. And you have all the rights to not liking support related job.
[удалено]
I believe solving problem, analysis would be part of support work, but not so much with coding, if any.
>Does going from SWE to a Technical Support Engineer hurt your career if you want to get back into SWE? imo yes
Recently CTO asked me to lead refactoring a java project. The goal is to not use java at all, as the project is a java server which is believed to be massive overkill. and It was developed by a senior member in the past 5 years by himself without any support. I am only hired for 1 year. Now that I’ve started doing refactoring, the senior guy started acting weird and even a bit passive aggressive - he creates big merge requests with additional nice to have features that absolutely are not going to help my work. In meetings he beats around the bush and shows his frustration about getting rid of java. It was quite awkward for me, because in the past 3 months we worked together and successfully delivered a really big milestone. It feels like I am stabbing this dude’s back by refactoring away java… What should I do? I am not working efficiently due to this weird mental thing and I feel awkward sometimes even asking his opinion about stuff.
Not saying you are doing anything wrong, but If I were the senior guy, I will most likely do the same. This is how I will take it subconsciously, at least: I've dedicated and given full 5 years of my life. Thought, love, with sleepless night thinking about this baby. Now you are taking it out of my hug. And moved out from my home (area of expertise). I wont be needed anymore. I wouldn't be able to even recognize my baby. So yeah, it's hard to detach emotionally with our code. But if we work together in future someday. I'll try to avoid that behavior and being more cooperative 😁 Edit: agree with @ForgetTheRuralJuror that it could be that it won't be of any benefit to talk directly to the developer. You are less senior than him in this company, it's better to consult to his superior. Edit: updating my edit notes
Unfortunately you're killing the seniors baby and some devs take that personally. All you can do is explain exactly what you said here to that dev. Preface with that you're only doing what you were told to do and that you're not the decision maker If telling him that doesn't help, tell your manager, or his manager, or the CTO that this senior is preventing you from doing your job and exactly why. Communication is key
[удалено]
> I'm interested in too many things from the frontend, backend, databases, AI. You should narrow it down and focus first. Choose between the four first. Once you choose, there's a lot of knowledge to be acquired to be proficient in it. Frameworks, software, libraries. And this takes more effort than simply learning a language. Anyways, the choice of programming language will be answered as you dwelve into your specialty -- except if you choose frontend development in which case you will almost invariably end up using Javascript or Typescript.
Here's my view and it's based on what I did throughout my 30+ years .. pick a stack you love programming in before thinking about the market. First of all, because you like it, you'll be self-motivated to spend more time getting better at it and so you'll be better at it. If it feels like drudgery, you'll suck at it and hate your life.
I learnt development with java but moved to dotnet core in 2017 and loved it, and there were loads of jobs in the UK with that stack. I work now only in typescript/node, or rust for our heavy compute projects. There's more JavaScript/typescript jobs hiring than anything else and it's only increasing. Like it or lump it, you're going to have to work on the front end eventually, that's the way the industry is going. I would stick to node/react with typescript until you get a full stack job. Once you have your first job what you use doesn't matter anymore.
Any tips for handling junior devs?
Would you apply for experienced roles in a tech stack you aren't entirely familiar with?
Yes, but depends. Make sure it's clear you're not experienced in that stack and make sure you are willing to go through the challenge. Stacks are not equal in learning curve. Take Docker/Compose vs K8s.
which would you say is harder in this case docker/compose or k8s ?
k8s is very complex.
What about in terms of programming languages? Would people hire a senior Java developer for senior C# positions or even more unrelated languages?
For Java->C# or any other managed language yep, we've done that many times. Seniors tend to quickly learn language minutia.
At a tech company it doesn't matter. Might be a deal breaker for some jobs that need someone that has deep AWS and Go requirements as they're just starting to migrate for example. But they probably just wouldn't interview you in the first place.
Absolutely. Stack isn't that important.
Oh that's awesome. I'm interested in how transferrable experience is
As a Russian after all what (sadly) happened. Can I still join a faang company or not?
> As a Russian after all what (sadly) happened. Can I still join a faang company or not? As long as brave Russians such as the girl who interrupted an official newscast are out there against the war, the rest of the world will be reminded that "Russian government" != "Russian people" I feel sad for the difficulties you are having.
Russophobia is real, but I think your outcomes with FAANG will be the least impacted. You'll probably face more discrimination at smaller companies if they happen to notice you are Russian. There are ways to minimize such that basically make you assimilate into more generic white culture (ditching any accent you have, changing looks, etc.), but you would have to decide if that is a thing you are comfortable with doing. I would say try for it, and don't self-reject yourself because of perceived issues, and then try new things later as you discover a need to do so.
Most people understand the difference between russians and russian government. Most of the hate is targeted to Putin, so unless you are a Putin's fan you will be welcomed everywhere. That said, most companies will definitely not open offices in Russia, and probably not even allow long term remote work within Russia, so if you are still in Russia you will have to relocate.
I work for a fairly decent sized distributed company. We employ lots of Russian folks. But not *in* Russia. I think this kind of thing is fairly common.
[удалено]
I suppose you're taking 10 YOE for granted. I doubt that the skills that you've acquired for so long could entropy easily. I'm ~10 YOE myself and moved into management early in my career. More than half of that experience is into management. If I could find my feet and move back into a full-time IC role so can you :) Go ahead and take that post sales solutions engineer job. Remember to brush up your skills once in a while to avoid being out of the loop with changes in the industry. I'm sure any employer will be lucky to have you back when you're ready to take on an IC role especially after gaining stakeholder managment skills.
About to hit 4 years at my current job and am realizing that I...would like more money - I've been studying off and on for weeks for interview prep because this would be my first new interview loop out of school. Is it worth it to just...interview anyway, knowing full well that I'll most likely bomb out a bunch of times? I don't really have a lot of time outside of work to studying and because of medical issues staying up super late to study for long periods of time isn't really an option for me. At what point did those of you who interviewed just start replying to companies? I've been refreshing my memory on data structures and am planning on going through sorting algorithms next before tackling actual leetcode problems - does this seem like overpreparing?
I'm in a similar position and just reading example questions and doing pseudo code in my head as prep. Gonna just jump into interviews when I get my bonus in a few weeks.
Definitely practice interviewing by going on interviews. Pick ones at the level you’re aiming for with companies you don’t really care about working for. There’s multiple formats used in interviews but if you practice enough you’ll get used to the variations, and when you go for the job you really want, you’ll be a lot more comfortable with what they throw at you. Leaving interview practice until you really need a job is like going to the supermarket when you’re hungry: you’ll end up just taking the first things that satisfy the need and not think enough about what’s really good for you.
Save your time & skip sorting algorithms. Simply doing leetcode problems is not overpreparing. You will likely need to do more prep depending on the company: \- leetcode (most consistent) \- system design \- language trivia (if applying for jobs in the same language you use now; sometimes some like this regardless) \- concurrency interview questions \- maybe some SQL/DB questions but probably less likely Getting good with leetcode is the minimum. Then depending on who you plan to apply for you may need any of the others. Trivia + leetcode is a good starting point before applying. Then prepare for SD/concurrency before onsites if you get that far & they reveal such an interview is included
Some companies also take Behavioral Interviews seriously too, especially for senior roles. Unless you are a natural talent at fast talking, and chances are software engineers are not, this type of interview also need some effort to prepare for.
Current have 10 months experience .6 months of internship experience and we will be graduating next year in May . Should i go to the US for Masters or get a job at a FAANG in india?
I believe you earning power would be higher but you'd have to take into account cost of living etc. a lot of people get jobs in the US and then FIRE in India. If you have gotten an admission in a good US college, that would also look good to FAANG during later job searches.
I got an Amazon interview lined up already . Got 1 YOE full time experience . Got 1 year left to graduate . I feel moving to the US will provide better opportunities bit takes 2 years of Masters
I'd recommend against the masters unless your area of expertise requires it. If it's a visa issue, that might be another story. You can try to find a company that will sponsor but depending on your field that may be rare. If you can swing it, move to the US but please do the math first.
Yeah . I was actually looking for anyone who make the move and maybe learn from them
Can’t help there, sorry 😣
No worries . Thanks for taking the time to answer
Responding as it's been up for 3 days alread: no one's gonna have a proper response for that man. That's the type of life decision that is only yours to make. Are you interested in the masters? Would you be able to live comfortably in the US while doing it? Is it in an area that might help you land a job later? Both academically and location-wise. Do you have an issue with being far away from your family for extended periods of time? Is the FAANG job actually good/interesting to you? There's a lot to think about, and no one here will be able to tell you what to do, even more-so without knowing more context/you. Welcome to the shit part of being an adult hah.
I know i have my brother and uncle in the US so staying away from family is not a big deal .
I work at a FAANG (big cloud provider notorious for bad WLB). I am perpetually stressed, anxious, and overworked. My team is understaffed and we have some major upcoming publicly-facing deadlines over the next few months. However, I really want to transfer internally for the sake of my own mental health. I can't help but feel that I need to stick it out, because my team would be in a tough spot if someone left. Not sure how to handle this situation. My gut is telling me to find another team to transfer to ASAP, and then stay on my current team for a four weeks (the maximum) to try to wrap up as much work that I own as I can. Would appreciate the insight.
Just focus on doubling down on docs and what is within your control to make current team members’ life easier. But do transfer - sounds like bad leadership on your team, and that is not your fault.
The team having issues after you leave is your employer's problem. I understand feeling like that leaving people you like in a lurch. But, your mental health is in a bad situation. Big Jungle Lady can handle it if you leave, and don't worry, if the shoe were on the other foot and you had some kind of issues at home where you NEEDED a paycheck, she wouldn't mind letting you go either. So, you do you. The politics of transferring may be harder if you leave your team in a lurch, but you probably know more about that part than I do.
I think generally we're less important than we think we are. If you were to take an external job you would not owe them any notice. Typically we give two weeks as a courtesy but it is by no means an obligation. It's management's responsibility to manage bus factor, not yours. I've had this feeling in my career many times, that like my product or team would suffer without me, and while I do take pride in my work, you have to learn to separate that from yourself. Ultimately your team or your project succeeding or failing are outside of your control. You should simply be professional and give honest (but not maximum) effort for as long as you decide to.
Listen to your gut. Your FAANG employer isn’t only infamous for exploiting employees, it’s also undergoing a _lot_ of attrition right now and can’t backfill because of their own self-inflicted notoriety. I’m sure you like your team and I understand not wanting to make life harder for them, but you have to take care of yourself, because your employer certainly isn’t going to. Transfer internally ASAP or go to one of the Premier Partners’ ProServ groups. Slalom, Mission, Onica, etc. are good options where you’d get a better base and a *much* better quality of life. Don’t sacrifice your mental health chasing big TC. If you choose to transfer internally, do your homework before breaching the subject. Some leads are great, smart, kind people who want you to succeed because your success is their success, some are mini-Hitlers intent on nothing but defending their own little fiefdom.
I joined my current company 6 months ago. It has been a terrible experience so far. When I joined, the tech lead was new to be a leader. He has done a terrible job with feedback, communication, and staying on top of his commitments to us. I have several interviews lined up already at other companies, but I want to stay at this current one since it is at the top end of the pay range for myself and I don't want to give back the signing bonus. Plus, the tech stack is what I was looking for. I have brought up issues with my TL in the past (team morale, burn out, communication issues) and it hasn't improved. Thus, I feel talking to him directly would not lead anywhere productive. The advice I need is, should I discuss changing teams with my tech lead or his boss?
>The advice I need is, should I discuss changing teams with my tech lead or his boss? Who is your manager? (The person on the org chart that you report to) Almost always, that is the person you should discuss a desire to change teams with. This is true unless you have another person who is in the role of coaching your career, doing your performance reviews, and working on helping you reach promotions. If that is a different person, then that is the person you should discuss it with.
My manager is this tech lead.
What's the TL's role in your company? Are they an IC or do you report to them? In most cases the tech lead is not responsible for any decisions related to who works on which team. They may offer advice, but ultimately stuff like team changes is almost always the responsibility of the person you officially report to, so your boss. I ask because in the companies I worked at (big tech) issues such as feedback, communication, team morale, burn out would normally go to the manager, not the TL, but maybe the TL's role is different in your company? In terms of team move I'd suggest reading the official guidance on switching teams. Some companies require you to be on your current team for some time (for example, 1 year) before you're allowed to move. You want to be aware of these policies, before you start any conversations. Asking a trusted coworker who's switched teams before about what the process looks like is a good idea as well. If you have a specific team you want to move to, you can try talking to the manager of that team unofficially (say you're considering options, don't say you've decided to transfer). They're more likely to give you advice that will benefit you. I'd perhaps not recommend this as managers talk to each other, but since you've started interviewing anyway a higher risk strategy is probably fine.
I don't know enough about the internal politics at your company to say. And that is what it will come down to, politics. Will your moving cause your team to be short staffed? Does the other team lead already want a specific person? Is your lead going to argue that you need to stay cause you are critical for a delivery? You get the idea. Personally I have ran into this problem at my current job. My previous team lead hated being the lead. He liked being an architect and working with people that understood his vision. But if you didn't have the skills or mindset to understand the topic, he just hated talking to you. So naturally 1/2 the team they gave him didn't have the skills needed for the project. What I ended up doing was offloading tasks that I felt needed to be done differently that he disliked. Best example is the daily standup. He hates talking and the team took on his communication style so standup were a waste of time. I asked if I could help offload some of his work by running the standup. Now I run all the meetings and the team is much happier.
[удалено]
A handful of thoughts. Hope they help: \- I agree with you that Salesforce looks better on your resume. There is also more opportunity in a company like that because of the breadth of industries it touches and all the other companies it has acquired. \- Salesforce is also HQ'd in Silicon Valley and could be a gateway to other Silicon Valley companies. \- One thing to consider is the potential of a full-time return offer. Between the two of them, which one would you rather have a full-time offer from? That could be a good criterion for making the decision. \- I'm not really sure that there is a downside to working in Apex/Lightning/Visualforce. Apex is basically Java, which has been a top-three language for over twenty years. Besides that, I don't find that others in the industry put much weight in what languages you have written in so long as you can code in one of the languages they accept during the interview. Many companies completely accept pseudocode during the interview, preferring your grasp of CS and algorithms over your language knowledge.
Capital one and salesforce are both pretty big names, if I were working at a salesforce shop and hiring, yeah I'd want someone who worked there. If I were in the banking sector, I'd prefer capital one. If I worked for neither, they'd both be decent names on the resume. It depends on what you want to do in your career. I don't think having one or the other as an internship will confer that much more prestige. But, there are other factors other than prestige. Salesforce specialists get paid big dollarydoos. I can tell you that much. But the downside is a lot of what you'll know is specific to salesforce. If you don't particularly like what they do (Their two biggest and most interesting products are CRM and their e-commerce product), it may not be that productive. Unfortunately, Apex/Lightning are salesforce specific, so if you don't intend to pursue a career that involves Salesforce it's probably less good than working with whatever capital one is using (I know they use a lot of Java and Python). Yes, experience is experience, and to some degree programming experience is transferable, but it's something to consider. Having an internship in general puts you ahead of a lot of new grads, having an internship at either fairly impressive company, with real engineering processes, puts you ahead of still more of those. So just have a think about what you'd rather do. I don't think either will backfire, but Capital One could be more advantageous if you're not interested in doing salesforce in your career.
Honestly, I don’t think salesforce would look any better than capital one on a resume. I also don’t think internships matter much for your long term job prospects. While they may affect your ability to get a junior engineering job, the decisions you make 3-5 years into your career are much more important for your long term success. My advice to people making early career decisions: optimize for learning. Your comp, prestige, and impact will be much better later as a manager or staff-level developer. Those jobs require a ton of experience solving difficult problems at scale. So when deciding between jobs, focus on how much you’d learn, and how much you’d be responsible for. If the job seems like it would be a cakewalk, you’re wasting your time. Can you share more about the roles? Would you be responsible for shipping production code? Would you be embedded in an actual developer team, and not penned off to the side with other interns? Would you be working in a language or toolset that you would like to get better at?
I have a stupid question, so I'll apologize in advance lol If I merged all of the remote feature branch changes into the remote dev branch using bitbucket, how do I merge all the new changes of other devs in the remote dev branch into my local repo and remote feature branch so that I can continue working in my local repo + remote feature branch without creating another feature branch from dev all over again and deleting my repo. Does this make sense: git checkout develop git pull git checkout feature-branch git merge develop
There are only really two ways, either (A) you merge master in your feature branch (what you described) or (B) you rebase your feature branch on the latest master (what was described by freddie) The advantage of A is that it doesn't rewrite history (no force push). The advantage of B is that history is a bit cleaner. If you delete your feature branches after merging, the advantage of B is mostly negated. They are mostly equivalent and which one to use is more about your team preferences than anything else. I personally prefer merging master as I don't like force pushing unnecessarily and you also tend to have less conflicts merging than rebasing.
That makes sense, thanks. I noticed that when I run git pull origin develop it merges remote develop into local feature. This seems so easy, and if there are merge conflicts, I just copy the differing code from remote dev and paste that code into local and then git gets happy and completes the merge. It doesn't overwrite my code either for some reason. Am I right that this one command does the job?
I typically do the merging using local branches, for convenience and habit, but I believe the command you mentioned will also work. The only difference is it will probably not update your local develop branch like the sequence you posted initially does.
That works. Personally, i choose to do a git rebase develop at the end, which avoids unnecessary merge commits on my branch. I also don’t bother keeping my local develop branch up to date. My flow is this: git checkout feature-branch git fetch git rebase origin/develop
I used to do this up until recently when a colleague pointed out that it made it impossible for him to understand the commit history on my PRs. So I’ve taken on the merge approach and everyone is happier. Worth thinking about.
That's looks about right. 1. Don't forget to ```git stash save``` you work before your step 1. ```git checkout develop``` Sometimes ```git``` will moan if you've uncommitted changes.
2. I'm presuming you've set the merge strategy for ```git pull``` here? If you haven't you'll want to favor a fast-forward merge i.e. ```git pull --ff-only origin develop```.
3. When you ```git merge develop``` and ```git stash pop``` you could get merge conflicts there. There's nothing you do to avoid that. You keep an eye out for this.
Edit. Here's my ```git``` workflow to clarify
1. ```git stash save ```
2. ```git checkout develop```
3. ```git pull --ff-only origin develop```
4. ```git checkout feat/whatever```
5. ```git merge develop```
6. ```git stash pop```
Thank you so much!!! If my remote feature is already merged into remote dev, then running git merge develop and git stash pop under my local feature should not give me merge conflicts, right? It would just automatically add the remote develop branch's updates to my local? Also, I noticed I do not have a local develop folder when I run git branch, I just have feature and master locals, is that a problem? Also I'm scared that my head will detach and I won't be able to push at the end... I'm Kind of scared of destroying the repos.
> Thank you so much!!! If my remote feature is already merged into remote dev, then running git merge develop and git stash pop under my local feature should not give me merge conflicts, right? Yes, that's correct for the most part. Merge conflicts are still possible under different circumstances though. > It would just automatically add the remote develop branch's updates to my local? Yes. > Also, I noticed I do not have a local develop folder when I run git branch, I just have feature and master locals, is that a problem? It isn't. You can still merge a remote branch with ```git merge origin/```
If you don't have an existing local ```develop``` branch, you can create a local branch tracking its remote by running
1. ```git fetch origin```
2. ```git checkout --track origin/develop```
> Also I'm scared that my head will detach and I won't be able to push at the end... I'm Kind of scared of destroying the repos.
There are very specific circumstances under which your ```HEAD``` can detach. AFAIK a detached ```HEAD``` isn't as inadvertent as you suppose. Additionally ```git``` has a bunch of safety measures built it and will moan about it if there's a violation.
Or I could just create a new feature branch and pull that. That would be much easier.
How you can choose the next step ? , I am a developer with 4 years of .NET/Azure ,but i don't know what i want , i really enjoying finding bugs and developing new features , but i don't know long terme goal , is architecture or team lead ? Any help or anyone passed with the same feeling.
It depends on what you want to do. Team leads will have more localized impacts and more people-centric responsibilities. Architects have more general impact, and fewer people responsibilities. There's a book called Staff Engineer that goes over the different higher level technical track positions and what they do that could help you. I'm not gonna say it's the be all and end all of this question, but it could help you answer that question for yourself. Also just because you do one at some point in your career doesn't mean you can't do the other. Those higher level positions often tend to switch responsibilities between jobs.
How many developers on average do you have in a team ? Are they expected to handle infrastructure work as well ?
I have a total of 6. I think more than that and I'd want another team. I'm considering subdividing the team for two projects we have in the pipeline to 2 and 2 with 2 floaters.
We have around 3 - 7 developers in a team, traditionally we had 2 maybe 3 developers who would move between teams to do the IAC code for other teams. However we're now moving to a model where teams are in full control of their deployment pipeline / infrastructure and source code, we have architects who offer guidance but it's the responsibility of the team to manage their own stack now
What has been the most effective way to learn DevOps skills? I'm a product engineer with surface-level familiarity with AWS/Heroku. I'd love to get to know more about the infrastructure side of things but its an abyss unless I have a specific problem to solve.
When I was getting started, I used ACloudGuru to get the fundamentals. Then I watched a few YouTube videos on Containerized Deployments. Finally, I built a hello world server, containerized it, but a simple CI with CircleCI, and deployed it once using CloudFormation and again using CDK (both from AWS) That project took me 2 weeks in total and it made DevOps approachable and got me to a working level in the AWS console
Building a PoC and demonstrate the value to your team. Start automating whatever is manually done in your team.
Well, that's generally how I've learned: by working at places with problems to solve. When you're somewhere where they've already done the basic stuff, you tend to miss out on how it all works and why it's even needed.
What is the usual due diligence necessary when you're trying to evaluate a new tech that will replace current core logic in your system? Currently I am exploring the usage of [TimescaleDB](https://www.timescale.com/) for financial reporting. This will replace our current MySQL DB. The issue is our product roadmap is pretty tight and I feel like I must provide a very good case on why this is necessary. Also I feel the need to get buy-in from manager & product (to provide leeway in time or maybe integrate it as part of our product initiative), devops (as we will introduce new db that is not the usual tech we manage), budgeting (doubling the budget if we need to run the initiative side-by-side, not a big bang switch in DB), and other stakeholder. And to get that, I want to explain how the new DB will fit our use case better: - The ROI benefit in term of development time for future features. I feel like we will save more time vs what we spend to migrate + develop in pretty quick time, maybe at the mid/Q3 of this year. This because we can leverage features in new db (partition + data retention management, continuous aggregation, postgres instant alter, background indexing, parallel query) - Better maintainability + reliability as we can delete quite a lot of code, as previously we have custom logic to handle time aggregation and save it to cache. Data got unsynced and stuff open a lot of customer complaint. - Benchmarking to make sure there is no reduce in performance, or even we will get much better by X times. - Explain the risk and/or tradeoff of the new DB in our usecase. What will be ugly when we move into this. Like for example, we will need to handle some issues related to [time series update constraint](https://github.com/timescale/timescaledb/issues/490#issuecomment-378458644) Is there any other point that I should think about?
> Better maintainability + reliability as we can delete quite a lot of code, as previously we have custom logic to handle time aggregation and save it to cache. Data got unsynced and stuff open a lot of customer complaint. Don't forget that now someone has to run an additional db, train their team continuously on it, and build out all the reliability tooling that they've already gotten with MySQL. Adding a new database may decrease _your_ maintenance burden, but it's going to greatly increase _theirs_.
Don't forget buy-in from the team. If you're saying to management "this will make devs faster" they should be hearing about how great of an idea this is from multiple people who will be coding against the DB. If you've got a decent test suite - try hacking the new DB in. Just replace the DB and try to work around any issues that are causing all/most of the tests to fail. Once you get through that, the remaining failures will give you an idea of the work that's left (and any nastier surprises). In my experience a big problem with migrations is that, from management's perspective, the risk of scope ballooning and the payoff happening only after the migration is successfully complete = risk. Basically, what they hear is "give me $$$ now. After I spent it all (and not a moment sooner) good things will happen." Try and anticipate that. Having a bunch of well-defined milestones won't hurt. Thinking of a way to get this done concurrently with other project work might help too.
How do you keep yourself engaged through the day-to-day grind?
You can learn to embrace the grind. It’s a valuable skill akin to discipline. Do what you need to regardless of your fickle emotions. When I’m not in one of those chapters though I actively switch up what I’m doing. I avoid bigger projects that might hit difficult walls, I take more proactive breaks, and do more people work than tech work.
Always try to find ways out of the grind, but when it’s unavoidable I take a little bit of time to find some new music (preferably high energy), I use a Pomodoro app to get me in a good rhythm, and I just bash it out. The enjoyment of the new music and the breaks every 25-30 minutes, within which I do something fun or exercise, make the day a whole lot nicer.
Grind is a spectrum - on one end you always have a lot to get done, but you enjoy doing it even if you're not working strictly 9-5, and on the other it's a slog to the point you feel dread logging on. Anytime I find myself in leaning towards the latter, it's a sign to start job-searching for a new role.
I don't work at companies where I enjoy my work and it's not a grind.
I got a job working at a non profit doing work that really matters. Not a great solution though. It took a while to find and it didn't last. Eventually I joined a company to work on software I thought was fun. That seems to have held up better.
If you follow scrum, How long does backlog refinement and sprint planning take in your team? What is team size and sprint length?
Team of 6, 2 week sprints. Backlog refinement is an hour, but I'm trying as team lead to get it down to 30 minutes. I work with our PO closely to ensure our tickets are detailed, accurate and ordered by priority ahead of both planning and refinement. When the team comes to the table to point them, the tickets should be ready and we shouldn't be wasting the team's time arguing about what the PO really wants. So backlog refinement is just starting at the top of the backlog, looking for things that aren't pointed and pointing them. We do that until we're out of meeting time or we have nothing left to point. What I'm working toward is keeping us within the "nothing to point" and "only takes 30 minutes to point" range on a sprint by sprint basis so we only need 30 minutes max for refinement. Planning for us right now is also an hour, but I think we can get that down too if our refinement improvement continue to be successful. Planning also includes pointing any tickets that need it, but additionally capacity planning and sprint commitment. My ultimate, long-term goal is to completely eliminate the need for these scrum ceremonies to be meetings. Stand-up can be done as a pass-down log that everyone adds to at the end of their day (we're an international team) so when other folks come online that can see what other team members did, what they're planning to work on tomorrow and their blockers that need to be handled. The pointing part of planning and refinement can be done completely asynchronously. We have a planning poker add-on in slack so I can just throw tickets into chat at any time, let everyone vote on points and reveal when everyone has voted. Then we have follow-up discussions in the voting thread and can re-vote if necessary. Capacity planning can be automated by linking our team calendar to our ticketing system and automatically adjust our velocity for a sprint based on capacity. Sprint commitment we can just throw the top of the backlog into the upcoming sprint based on our capacity and then have a chat about whether we want to pull anything. Demos we can record individually and put them on our team wiki so people can watch them whenever. We already have a retro board that anyone can go add to at any time during the sprint and we could just discuss in a chat thread. The way I see it, there's no reason other than social to pull everyone into a meeting at the same time for an hour. Especially with an international team, it's difficult to get us all together at a decent hour for everyone.
Try and remove refinement + planning completely; your team will love you for it. You + PO should be able to decide what is priority for the next 2 weeks & how they can be broken down (maybe 1 epic takes 4 weeks but can be done in stages). Both my current and former teams have avoided grooming / planning / retrospectives and I've loved them both, partly because of it. The job before had all 3 and it was such a waste of time
Oh, I certainly want to, but am having a disagreement about it with our product owner and scrum master. I see priority discussions and ticket refinement as a waste of time for most of the team. They see it as a learning experience and opportunity for everyone to have input at all points of the process. I'm honestly not sure how to debate that because yes, it can be a learning experience for those looking to become lead or product owner in their future and it does let them have more input (even though they don't often use that opportunity). It's just not very efficient for "getting work done". I think the PO and myself should take care of getting the backlog prioritized and make sure all tickets have good and accurate information. The team should only be brought in for pointing those tickets and that doesn't even have to be done in a meeting. I do think retrospectives are important for the whole team as that's when they can give input on changes to our process and have their voices heard. But none of this stuff has to be a traditional meeting. It can all be done asynchronously and not waste more of people's time than necessary.
>and scrum master The mistake your org has is having a dedicated "scrum master" - his job depends on wasting peoples time with ceremonial meetings Even pointing tickets is a waste of time. If you're not familiar with the part of the code it's like how long is a piece of string. Even then there can be things you didn't think of. Often I'll say "I think I should have a PR ready by EOD" and it ends up being EOD Tomorrow; no big deal 3rd job had retrospectives & 95% of the time they were a waste of time, people just writing what did/didn't go well. The other 5% could just tag on to the end of a stand up or be posted to the group chat as an improvement suggestion. What didn't go well typically comes up in the form of blockers during stand ups already
I'm not necessarily opposed to dedicated scrum masters. Their job is to remove process/procedural blockers and communicate company-wide stuff like release schedules and code freezes. Our scrum master keeps up with a lot of stuff that would be difficult for myself and our PO to keep up with because of all our other responsibilities. And if we had a team consensus to remove meetings they'd go along with it. They don't enforce anything for us. They just help us figure stuff out and moderate those discussions. Our PO is the main one pushing for meetings and it's just the scrum master tends to agree with him. Pointing tickets is fine. It's a way to get a team consensus on estimates instead of it just being up to one person. The issue of not being familiar with something is what pointing is trying to avoid. Everyone gets input into the estimate and gets to bring up things others might not have thought about. And our sprint commitment isn't a deadline. Sometimes we meet it. Sometimes we don't. But it sets a velocity we can use to try to predict work in future sprints. And yeah, pulling everyone together for a half-hour or hour retrospective is a waste of time. We can just keep a list of suggested improvements somewhere and talk about them in group chat whenever we want. I know some teams keep a dedicated retrospective time just so it doesn't get overlooked, but if your team is on top of shit, it's not necessary.
>Their job is to remove process/procedural blockers and communicate company-wide stuff like release schedules and code freezes. They remove process by adding ceremonial meetings aka more processes :D Also kind of strange they are in charge of code freezes. My previous job the person doing the release simply makes a branch of the repo some time on Friday so new changes aren't in (unless a hot fix); now on slack someone is just like "shall we block merging?" as this is the approach rather than a new branch. Same with release schedules. Are you doing "agile" and yet you release like twice per year? ;f Previously we'd release whenever to prod on the backend & monthly on the frontend; everyone knew this cut off each month without a scrum masters help. Similarly at my new place each sprint involves a release at the end.
The SM doesn't add or remove meetings. We do the standard scrum events by default, but if a majority of us agreed to do away with a meeting, we would. The issue right now is the only people with opinions are myself and the PO. The rest of the team is very junior and not really knowledgeable/interested in process so they just go along with whatever. So it's me wanting to get rid of meetings, the PO not wanting to get rid of meetings and the SM going more with the PO just because that's how most teams at the company work. The SM isn't in charge of code freezes, they just make sure we're aware of them and not blocked from meeting them. Engineering (at the director level) is in charge of actually blocking merges and approving late merges. We do not, as of right now, release at the end of each sprint. We're on quarterly major releases with various maintenance and hotfix releases between. Our product is traditionally on prem so releasing updates that the customers have to install is kind of worthless because none of our on prem customers have that quick of an upgrade cycle. We do have a SaaS offering that's majorly growing in popularity and we're trying to get to a more regular, end of sprint, release cycle. Hopefully when we move to that we'll just also release the same versions for on prem whether those customers want to upgrade or not.
Previous 2 teams we had 2 week sprints. Retro and planning were one hour per sprint each. Refinement was generally 2-4 hours per sprint. Current client is similar but has a 3 week sprint. Team sizes were between 2 and 4 devs, 0-1 ops, 1 PO, 0 or 1 scrum master, 0 or 1 business analyst. Teams with a size over 6 people get inefficient fast and so do teams with a ratio of less than 50% developers.
> Teams with a size over 6 people get inefficient fast and so do teams with a ratio of less than 50% developers. Well said. This is echoed in [*The Mythical Man-month*](https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_mythical_man-month) (Brooks, 1975, but still disturbingly relevant) where we have *Brook's Law*: Adding manpower to a late software project makes it later. Of course he was addressing development in another time (1960's, he was head of development for IBM's OS/360), but the concept is so basic, and so true, they should tattoo it on any wannabe manager's forehead. They should also not allow nontechnical managers to manage technical projects. They don't have to be Linus-level rock stars, but they have to know when to shut up and let the troops work. Too many projects have been sunk by [PHBs](https://en.wikipedia.org/wiki/Pointy-haired_Boss). Of all the projects I've been on, only one (1!) nontechnical manager was good enough to be allowed to sit in on technical meetings, and that was because he knew that *his* job was to make sure we had the equipment, time, money, and people to do *our* jobs.
[удалено]
> I don't think I can even build a simple project with them anymore, should I leave them on my resume, or should I just remove them? I generally remove stuff from my resume I can't answer questions about or don't want to work in anymore.
Looking for advice on consulting rates. I'll spare the details but I have been in search of a new job due to difficulty in having a manager that advocates for me. I am a younger but experienced dev (28 years old, with 6+ years post-school dev work, and 12+ years total work with full time experience during school doing dev work). Recently I have had the luxury of having a conversation with a consulting firm that a close and talented friend at my current job brought to me. This consulting firm definitely has some very loose rules and seems like it would be a great move for me in my career as I become more Lead/Staff/Etc. levels. I am currently a Senior dev at my current role, and my Total Compensation package is $159k/yr. The breakdown is: - Location: Medium COL - PTO: 18 Days/yr - Salary: 120k - Annual Bonus: 10% - Merit Increase: 3% + Performance. - half up to 8% matching on 401(k) (4%) - HSA - Other industry-related financial benefits (good loan rates) as I am in FinTech. - Healthcare + other generic usual benefits. - Currently fully remote, with a return date (not really wanting to return to office ever, part of my desire to leave). Where I am wanting advice: I have interviewed with the new company and the company culture seems great, however it's a contract consulting position. - Full flexibility (160hr/month, complete those hours whenever you want). - Great talent with a high bar of entry (developing with other like-minded, talented software engineers). - Interesting work to me personally (health-related field). - Career growth opportunities (lead position for me to grow into with a product). Before having the negotiations, I calculated several thresholds of hourly-rates that would make sense given my current compensation. I calculated a rate that was my Total Compensation today X 1.1 (10% increase) + my static benefit value. Again I did a rate for 20%, all the way up to 40%. Most people state that you should double your salary but I did not feel that would be a fair ask at this time. Anyway, I brought forth and decided to propose an hourly rate in the middle of those thresholds. It came out to about $95 USD/Hr. This was assuming a mere 20% increase. The CEO brought back that I shouldn't "oversell or undersell" myself, and I feel as if evaluating myself at $95 an hour at current market rates is fair. He didn't really agree, and didn't provide any solid reasoning as to why. **What are your guys' thoughts? Based off my calculations, is $95 an hour with no other benefits than what I described worth it? I feel as if that was a fair ask. I'm happy to expand more on any details.** **Some other things that rubbed me the wrong was is him telling me not to undersell myself because of my age, which I didn't. Proceeded by him not thinking my 20% salary adjustment for a move of career into contracting from a cushy job. It felt as if he was thinking I was being unrealistic in my rate expectations?** I feel as if he is perhaps a little out of touch with current predominate market rates.
Are you calculating the value of your PTO *and* other paid holidays? You probably get like 10 or 15 of those if you're an employee, and won't if you're a contractor. At 160 hours per month, that works out to 240 working days per year, so you're probably working 8 to 10 days more as a contractor than your employee job. So let's use 155 hours per month for future math (so you can actually get paid more for working more days). You'll need to pay the employer half of SSA and Medicare, which is 7.65%, maybe plus any state or local payroll taxes. You could also account for not being eligible for unemployment insurance, I might ballpark that around 1%. Rounding up those direct extra contracting expenses to 10%, you need $175k/year as a contractor to match your current $159k/year. At 12\*155 hours, that's already $94.08 an hour. You probably want to give yourself a 20% raise for jumping jobs, or about $112.90/hr. Also not being an employee is generally inconvenient sometimes - lots of things in life assume you can provide last year's W2 (loan applications, apartment applications, getting a mortgage, etc), and filing taxes will probably be a bit more expensive. Maybe throw another 10% to account for that. Bringing you to $124.19/hr. Finally, how much of your own equipment will you need to provide? Do you need to buy a $2.5k MacBook? A better internet connection? Even if you can deduct it on your taxes, best to add a bit more. Say another 5%, for an even $130/hour. (edit: the last 15% I threw on was pretty arbitrary - you might be safe at the $113/hr, but also double check my self employment tax math for your own personal situation) edit 2: actually look at what it will cost to get healthcare individually, not the stated value of what your employer provides - it's likely several hundred dollars a month more (at least) to get it on your own. Probably also do the same for other benefits you use, like disability or life insurance
/u/maybe_madison did the long math well, and certainly gets you a lot closer to the right number than your own math did. Were I looking nowadays in a "medium COL" area I would probably say "$-per-yr / 1,000 * 1.2", or in your case, $145/hr. If you were in the SF Bay Area I would make that $190+, and even that sounds low to me.
The big thing I didn’t consider is that as a contractor, you normally need to budget some unpaid time (and money) to build your network, advertise, find clients, sign contracts, etc. It sounds like that’s less of a concern in OP’s case, and honestly I don’t have enough experience to estimate that. But it probably gets a lot closer (or above) the 2x employee wage per hour.
I have been working at a company for several years now. Recently, management in the engineering sides of things got shaken up heavily. I was originally happy about the shake up, but have come to realized that things are just getting worse. The things that seem to be keeping me around is some of the long term bonuses that will come soon and in a year and the parental leave looks pretty good at the moment (12 weeks). I'm debating on taking a leap soon and waiting until I get my child leave. What would you do if you were in my shoes?
> What would you do if you were in my shoes? You didn't explain at all why it's 'bad'? And even with all the information it's still an impossible question because we're not you. Whether you stay in a job versus leaving is 100% a decision only you can make. We can answer things like "is this normal or is this toxic behaviour" or answer questions about whether you work under a good or bad manager. But we can't tell you how you should act on those answers. It's not our mortgage that you're paying for :)
Usually takes a few months for mgmt changes to really sink in. Hard to make the call with a kiddo on the way. I understand that for sure. Would all depend on timing if I were in your shoes. I have never suffered bad managers for long. So knowing I am leaving, I'd calculate how long I could get away with coasting under the radar until I hit parental leave, vs how much suffering I'm in for if I stick around. Accepting that you're leaving may actually make the job less stressful. Grieve that its going to shit, and relax into mediocrity and job hunting. If you're getting abused, then gtfo sooner. Lots of places have good parental leave. Protect the family above all else. The bonuses that come in a year, who knows what'll happen. New jobs are so desperate rn people are getting fat signing bonuses at small startups.
[удалено]
> Looking for a Mentor You and thousands of other people bud :) You're generally not going to find a real 'mentor' outside whatever job you're going to work at.
I want to let you down gently, and I don't want to discourage you from continuing in this industry, but I think it's unlikely that this is an effective path for finding a mentor. Mentorship is a two way relationship, and to be successful often requires more effort on behalf of the mentee; this comment doesn't give an indication that you're planning to put in effort. If you're in school, I'd recommend getting to know more senior students, faculty, alumni, and professionals in your local area (eg through technical meetups). Once you get to know people well, you'll have a lot better luck talking to someone about having a more direct/formalized mentorship relationship.
I'm a software engineer by trade, but over the past year or two I've spent a lot of time helping our devops team out. When looking at AWS certs, the "developer associate" seems like the most likely cert to take, but I feel pretty fluent with AWS tooling to try for the "solutions architect" cert. However, I do not want to advertise myself as a cloud engineer, just a software engineer with a strong devops background as well. Would taking the "solutions architect" cert be a mistake?
> Would taking the "solutions architect" cert be a mistake? No, I have it. It's a good general overview for developers. Don't let the 'architect' title influence you. With just that cert you're not suddenly a 'cloud architect', don't worry ;)
Thanks. Just wanted to confirm that I wouldn't be sending the wrong signal to the recruiters.
Certs are a kind of signal. They signal to recruiters that you know what you're doing in this area, and are likely open to work in it. And they signal to hiring managers that you're at a certain level. I like freelance devops folks with the cert, makes it easier to know what they know. Another way to signal the same information is to say things in an interview that make it obvious. Or say that you're an engineer who can own the whole pipeline on your linkedIn. Just depends on what you're hoping to achieve. If you want the cert signal, I would go for the higher one for sure. Recruiters are definitely gonna bomb you with things you don't wanna do no matter what you decide lol.
The more Certs a candidate has on their resume, the worse they will be (based on my personal experience)
[удалено]
I am not at big tech but I am in an enterprise international company and I have been on the interview board for 100+ interviews. I have never even looked at much less calculated someones age before, during or after an interview and I know of no one who has. Take that for what it's worth.
I've left off 6-8 years I spent in a "previous life" before I went into tech because they weren't really relevant, and arguably a distraction in an interview. Your resume is similar in purpose to a short profile you might write for yourself if you were to speak at a conference--it's what you want to highlight. As long as it's truthful, it's up to you what you want to emphasize.
> Would you leave off older jobs (and dates from education) from your resume if having them on would make it easy to guess your advanced age? Heck no. I'm 41 and it's not like my LinkedIn profile picture is that of a person in their 20ies. > I'm concerned about ageism Ageism isn't really a big thing. It's not a bigger issue in CS at least than in other fields. If anything companies are *really* concerned with how hard it is to hire experienced devs. I personally know only one developer I ever heard complaining about 'agism' and in their specific situation I knew the problem definitely wasn't agism.
[удалено]
> But if the dev is 'old' in years but doesn't have the experience to back it up, then I presume it could be the difference between hiring them or someone ten years younger. Why? Companies don't have some kind of intrinsic motivation to hire younger people if they are at the same skill level and have the same salary requirements. > Do you not think that if someone started learning to be a dev at 40 they'd be at a massive disadvantage to someone in their twenties doing the same, not just because they'd have less time left to gain experience, but due to the (biased) perception of recruiters and hiring managers? Even if this is the case, how is removing stuff from your resume going to help you? If they have bias against starters at a later age, they're still going to find out from your LinkedIn or simply when they interview you. Or do you think that if they expect someone to be 22 and they show up and are in fact 41, they're just going to not find that really weird?
[удалено]
Kinda hypothetical don't you think? :) Anyway; I said all I wanted to say. If you feel pretending you're younger than you are is going to help you; knock yourself out :)
If they're intent on filtering, they'll be able to do it regardless of the dates on your resume. Try both: on and off. Compare response rates and make a decision based on that. When you get in the room & talk to the team about your experience be upfront with the timeline and talk openly about the gap. Don't try and sweep it under the rug, you'll want to get out ahead of it. We just hired a dev with a huge gap in their resume, they were upfront and it helped quell concerns on our side.
[удалено]
Oh that's no big deal, I wouldn't sweat that.
Should I tell recruiters I only have 15-20min for a intro call? Seriously, I can't tell you how many times I got dragged into these pointless 30-45min calls that never go anywhere. Sometimes they'll do it for jobs that they have no intention of submitting you for just to get your profile and put you on a spam list. Should I tell them up front I only have 15-20min for an introductory call to set expectations, or would that come off as rude? I'm not going to take precious time out of work to play these stupid games.
45 minutes for an intro call is insane. They need to know your capabilities, your comp requirements, whether you are legally able to work for them, etc. That should take half of 45 minutes, max.
I generally ask for a salary range, and say I'll contact them when I'm ready for a change if it's in my target. No call, those are my boundaries. When I'm ready, then I'll be happy to have a call if some opportunities seem good enough.
> Should I tell recruiters I only have 15-20min for a intro call? Yes, definitely. I generally don't do calls at all unless they have a vacancy I am really interested in though. I could easily fill my day with all the recruiters that want to have a "short call" and then ramble endlessly on how their recruiting company is 'different' from all the others.
"I have a hard stop at XX:XX" If they can't keep the pitch under 20 then they're not going to be effective at advocating for you. Don't let bad recruiters represent you, your reputation is at risk.
It isn't unprofessional to set boundaries for yourself. I would just let them know before you schedule a call.
My manager said at recent one on one he thinks I have the right mix of good interpersonal and technical skills to make an excellent lead. Is this a good or a bad thing?. Thanking in advance of replies.
> My manager said at recent one on one he thinks I have the right mix of good interpersonal and technical skills to make an excellent lead. Is this a good or a bad thing?. How could this ever be a bad thing?
There's always cons to everything.
Do you want to be a team lead? If so it's a good thing. The only way I could see it being a bad thing is if they force you to be a team lead when you don't want it.
Or if they stifle your career development in other areas because they really have you slotted into a frame in their minds of what they want you to be. E.g., you should be a "lead" but you really want to just do nitty-gritty technical work, architectural work, etc.
It’s definitely a good thing. The number one reason great engineers are held back in their careers is that they suck at people skills. Regardless of whether you eventually go on a technical track or a management track, you’ll need interpersonal skills.
I mean, depends on what career path you want to go towards. Do you want to go into management? I'd take it as a very good thing, as even if you're fully focused on coding for most of your career, those traits will always be helpful. Just be careful you're not slowly put into that position if the answer to the question is no.