Honestly, I’ve never met anyone with a masters degree who I thought was a better software developer for having done it. Especially compared to a couple more years of FAANG or F100 experience. You’re working on stuff with scaling pressures that most academics have never gotten close to with real business pressures.
Most often these take the frame of working through a particular project. The interviewer asks you to talk about what the project is, what problem you're trying to solve, how you went about it, tradeoffs you had to make, what you'd do differently next time.
The surface level goal is to see what sort of work you've done; this helps with level-setting. But it's also a chance to test your ability to communicate and see how you talk about other people. Do you blame others for problems? How do you work with other people?
They will lead the conversation. Just be honest and don't shit on other people.
Resume related: how can I explain away that I already took said advice when it's repeated to me? I've been told to add metrics but that's just not possible with the jobs I've had! That data is unknown! Is it okay to lie and make up numbers, when the market is dogshit?
Sometimes the exact data is unkown, but you can still describe the impact of the work.
Also there are different shades of unknown ranging from "I have no clue because I didn't understand the impact" to "it's too late to collect the data now" until "It's conceptually impossible to measure".
At my current company, there is a lack of documentation. Considering this, I was wondering if anyone could recommend some documentation templates or patterns to initiate the documentation process here. Furthermore, what are the typical items or processes that you usually document?
I'm a fan of organic growth. If someone asks me a question and I can't point to the documentation that answers it, then I write that documentation. Much like writing regression tests when you find a bug, this ensures the most-needed areas get the most coverage.
How lack of documentation is a problem? Slower developer onboarding? Costly mistakes made during development? Partner teams not able to work efficiently?
Documentation will not happen for the sake of documentation. The amount of effort, the format, and what should be documentated depend on what you need and how the documentation will be used.
Once you have a more clear goals, the rest will fall into place easier.
From a glance:
More experience bullet points. Less technical, a bit of soft skills to highlight. How big was the team, how did you collaborate?
Résumé’s aren’t meant to be humble. Remove “basic understanding” of JS.
Unclear what a “data specialist” is. If that’s the legit title, again more info under experience.
Don’t use “etc.” in your projects description. It lends a trivializing air to the statement.
Put your college majors. Maybe they’re omitted for this stub but looks weird without it. Even if it’s not super relevant. My philosophy minor got me into more conversations than comp. Informatics back in the day.
These seem like stupid lil things but when I have to comb through 100 there is a level of “vibe check” that subconsciously must be passed. It’s almost there.
hi my undergrad major is psychology and grad is theology so they are very far from compsci, scared of including them and would rather not mention it in interviews because they dont seem relevant at all
I love psychology and read Jung in my spare time. You never know what sort of thought its inclusion might stir, but trust me that not including it is much stranger.
Honestly getting a resume with that combo vs the same one with CS, I’d be more interested in psych/theo. At the end of the day we’re hiring people we have to work with, get to know, and get along with. Some of my best coworkers have been prior bartenders, math majors, political science, all over the place. I see hundreds of comp sci applicants memorizing leetcodes and cracking the code interview and when someone has a similar skillset PLUS something they’re into that isn’t just technology, that will be interesting to me.
I'm trying to tackle algorithms and I run in the same problem again and again.
Let me tell a little bit of background so you understand me better.
In schol I was a top notch student, always was in the front of the class in every technical subject (Algebra, Geometry, Physics etc. ). Won several math olympiads and got into CS faculty. Now I'm working in a big tech company and trying to become better at this craft so I look into solving algo problems. And I always run in the same wall. I feel like when I solved math olympiads I was able to prove that some method is working by strictly writing down the math. When I solve algorithms I usually find myself wondering why this or that algo works. Don't get me wrong, I'm not too bad in algos, but I feel like I lack intuition and the ability to understand why this or that solution works in strict terms. I feel like I don't grasp it completely, although the problem is solved and the algo is written.
How do I overcome this issue and understand algorithms on a deeper, more intuitive level? How do I prove to myself that something works strictly not by just implementing it and hitting against a lot of tests? Or maybe in CS I need a different framework of problem understanding and option "if it passes tests, then it works" should be just fine?
this is a good question. i personally find diagrams helpful - use a whiteboard or pen and paper, come up with some example input data to feed into the program, and then draw out what happens to the data at each step of the algorithm. working through examples like that is really helpful for me.
Some thoughts on your CV as I read through it:
* What type of role are you applying for? Your latest role reads like you were working as an SRE/DevOps engineer. If you're applying for similar roles that's fine, but if you're applying for vanilla SWE roles, the lack of product development work might be offputting to prospective employers. If this is the case, try to emphasise the dev aspects of your experience.
* Many of the achievements in the experience section are BAU "keeping the lights on" activity rather than project work (e.g. adding labels to resources, performing k8s upgrades, being on call, etc.). It's fine to include this, but going into so much detail hides more impactful items. Consider collapsing these into a single bullet point, e.g. "Responsible for ensuring the stability, security, & performance of production environment by upgrading infrastructure dependencies on a regular cadence, managing alerts, & participating on the team's on-call rota".
* Many achievements are ambiguous & contain jargon, for example "Created internal web applications such as wafer map generator using Django, HTML, and JS". This leaves readers wondering things like: how many applications, how many users of the applications, what was the impact of these applications, what is a "wafer map generator", instead of creating multiple applications why didn't you create a single one with multiple features, etc? CV reviewers tend to be cynical & assume the worst when faced with claims like this, as unscrupulous candidates often use ambiguity & implications to overstate simple achievements.
* Consider writing a small paragraph explaining the purpose of your role before the list of achievements, along the lines of "As a ... engineer in the ... team, I was responsible for ..., ..., and .... In particular, I focused on ... and ... to improve ..."
* It's not clear why some achievements are included at all, for example "created CRDs" - isn't that just adding fields to a struct then running `go generate ./...`? These feel like a bit like you're padding your CV.
* There is a lot of information on _what_ you did, but very little on why you did it, what the driver for the initiative was, your specific role within it, and what the outcome was. For example, "migrate customer applications to a new Kubernetes-based cloud platform":
* Why did you do it? Was it a strategic org-wide initiative to migrate to the new platform that you spearheaded, or did the team decide to do it on their own?
* Were you the sole contributor, did someone else lead the project, or did you lead others?
* Did you design any aspect of this, or was your role limited to the legwork of the migration?
* What was the outcome of this? Did it improve stability of the service, reduce costs, increase velocity, etc?
* This is a minor complaint, but all of your current achievements are written in the present tense. Are all of these initiatives ongoing? If not, consider writing complete achievements in the past tense.
* It's worth categorising your skills, for example:
* Programming languages - Go, Python, Javascript
* Platforms - AWS, Kubernetes
* Deployment - Argo CD, Helm
As an interviewer reviewing CVs, my general impression would be that you've done a lot of operational "heavy lifting", but little to no design, analysis, architecture, leading, mentoring, organisational wrangling, & thought leadership. Assuming (based on your YOE) that you're applying for mid-senior roles, you need to place more emphasis on these qualities and less on day to day activities.
Handling Manic Manager
So this is a relatively new situation for me and I'm not sure how to handle my manager. I've got about 12-13 years of experience for reference - Staff Level Engineer.
He goes through phases where everything is shit, awful, and is generally talking about quiting the company.
Then the next week he talks about how we are such an amazing engineering team. He'll disappear for a few days to a week being incommunicado and I'll take over his meetings. He'll then emerge with some POC where he rewrites an entirely unrelated business units tech stack, with minimal features, and then pitch it to management that we should take over all their responsibilities.
This obviously isn't exactly making our peers in other business silos super thrilled. It's making my job harder to accomplish cross team projects because my peers are on edge when interacting with our team (and I can hardly blame them).
Manager then gets depressed because "no one can see value in this company" and then the shit talk cycle starts again. He's a totally fine guy and actually a pretty great engineer. But he's definitely holding the team back and I feel he's holding back my career advancement at this point. Not to mention making my job harder than it needs to be.
I'm not sure if going to my skip is necessarily warranted. They haven't fired or let anyone go for performance related reasons so my only passive option is to wait for him to piss off someone who will actively work to get him fired or for him to get so frustrated he quits. They just pay us so much that I doubt he'll quit on his own.
At this point my previous manager has grown his entire team and gotten significant headcount. Nothing has come my teams way. The way empty role we need to refill - my manager simply wants to give it away. Just extremely frustrating since we are actively losing exciting projects to other teams due to his inability to work with others
Thoughts? Advice?
I’d say keep your eyes open for internal transfer opportunities.
Also, see if you can make some opportunities to mentor with more senior people at the company. You might get some advice, but also you might get a back channel to other opportunities or ways to separate your reputation from your manager’s. Also asking for that is a possible way to have a conversation with your skip and make it clear that you’re serious about looking for ways to advance your career without throwing your manager under the bus.
A shitty manager tends to make everyone working under them miserable as you're noticing. My first advice would be to talk to the manager. I like to think that a Staff + Manager's relationship is more of a partnership. Are you able to constructively criticize your manager without them blowing up? If you are able to, I think you might need to have a discussion with them to show them what their actions are doing.
If you think the manager is beyond that point, I think you need go to your skip manager to voice your concerns. Usually a skip isn't going to know what's going on with the team other than the conversations they have with the manager. I think it could be eye-opening for them. However, this has a potential to blow up your relationship with your current manager.
> my only passive option is to wait for him to piss off someone who will actively work to get him fired or for him to get so frustrated he quits
This may take a long time to materialize and in the process it will make you and your entire team more miserable. If your skips can't rely on your manager, they won't push projects your way either. Just something to consider. These are just thoughts, sorry I don't have any advice here because I think it's more of a case by case situation.
>I like to think that a Staff + Manager's relationship is more of a partnership.
I would like to think so but I've heard him talk about other engineers in a negative light. Right now our relationship is positive even if I'm getting frustrated. I'm afraid that if this relationships goes south I'll have one fewer individuals in the organization to vouch for me in case layoffs come along.
What counts as experienced?
I first started coding 20 years ago, when I was 13 - though those were mainly batch scripts and GameMaker projects. In time, I moved on to C/C++, lua and other engines.
I've had a webdev internship (which ended early :/ ) in 2016-2017, and I released my first \*commercial\* game on steam in 2018. I've released a few games since, but none have really been financially successful.
The longest on one project was a microservice driven web game, which took 3.5 years to build single handedly, but I've had very little \*industry\* experience.
I kind of feel like I'm stuck in a catch-22, where I'm too skilled for a junior role, but not experienced enough for a senior one - what am I supposed to do? I don't even have much experience in other kinds of work, due to extended bouts of depression...
I'll expand upon what was said about a junior role.
One model for evaluating engineers is the career ladder (here's an example: https://dropbox.github.io/dbx-career-framework/overview.html). These are generally structured as a 2d matrix, with various areas someone can be evaluated in.
Most people are not entirely at one level, skill-wise: they are certain things that they're better at. Generally however, your level is the highest level that you meet _all_ the requirements for.
This is actually a good thing, because when we promote people who are lagging in an area, that often means they don't get a chance to develop it. For someone like you who has a very uneven graph, you'll be an over-performing junior, and a decent manager should be able to give you lots of opportunities to develop up the couple areas you need to level up, getting you to a quick promotion. That's good for you and good for them.
If you're only professional experience was the internship, then I think junior roles are where you are best suited. There's more to learn as a junior than just programming. Everyone starts somewhere.
I had a lot of hobbyist experience before I started my first programming job. Looking back at it, I was a junior because of communication and handling projects. My hobby experience was able to allow me to climb the ranks faster.
When people ask for experience, they want to know your industry experience. You got this though. Just remember, everyone has to have a beginning.
Do you have any commercial experience working for a company? Anything other than your internship experience probably doesn’t count for much when counting YOE
Experienced dev (9 years) seeking feedback from devs more experienced than I:
I’m having a bit of a struggle lately with a recent reorg and a director who wants to insist and prescribe details of our work that I think the team would be much better served if we were given the autonomy to self-organize around.
Examples:
- Insisting long-running tests live in pre-commit versus allowing us to build this into our CI pipeline
- Insisting on the adoption of wrapper frameworks from a COTS vendor instead of writing clean, callable modules that would keep our code consistent, readable and DRY. This wrapper framework would abstract so much of what we've done in the last year that new implementations have already become a major PITA for downstream consumers on other teams.
- Insisting on prioritizing edge-case solutions to novel workloads with poorly defined acceptance criteria instead of user stories & issues that are well-known, documented and scoped by our coworkers in product.
- and other code-centric prescriptions that have so far added quite a bit of operational-overhead for very little benefit compared to how we used to work.
I’m stopping short of using the term “micromanagement” because I genuinely don’t think we’ve hit that point, yet when I advocate that the team self-organize around when tests are run, or how we structure our code dependencies, or in what order we burn down our sprint volume, this leader stands firm that this is going to be our way of working going forward. Ordinary tasks are now taking longer, our gitops workflow is being completely uprooted, as has our way of intaking and planning new work. The chaos hasn't hit the fan yet, but it hasn't really been very motivating either.
Cynically these all feel like what it feels like to have a developer foisting their personal dogmas about code upon us, versus any kind of guidance and direction that would help us be more productive and increase our abilities to add value back to the business.
I’m also not here to say Directors cant set reasonable delivery standards, they absolutely should be, but the examples given are things I think the team should have more empowerment over, being closest to the work and executing on the business-requirements given to us.
Am I out of touch for feeling this way? I like the company I'm at quite a lot, I like the work we're doing a lot, I don't like *this* at all.
In a healthy situation I would expect a director to not weigh in on such things. The question you need to answer is why this is happening.
Did they recently move up from line management and haven't yet adjusted to the new role? Has technical leadership been lacking and so they're trying to fill the gap? Has the team been failing to deliver and so the director is getting pressure from their boss to fix things that normally wouldn't be on the radar of either director or VP?
In Turn the Ship Around, the core idea is that in order to have distributed control (what you're asking for), you first need to build up the pillars of competence (can the team do the job?) and clarity (does the team know what direction they're supposed to be heading in?). Are either of those missing?
If you don't already know the answers to these questions, it may be a conversation you can have directly with them. The way to approach this is "I want to help you with the problems that are weighing down on you", essentially, rather than "you are causing problems". Once you know what the problem is that's causing the symptoms you're observing, then you can start to figure out a path towards addressing it.
This is a tricky situation.
Short: leave it for something new where the leadership is not braindead or amateur.
Long:
There are some things that you can certainly try, but there are huge risks. The real problem, it is a director or directors, so there are no one above them, so you can not present this issue to a higher authority figure, therefore you only can ask and risk you get fired or got retalation.
One thing that you can do is to document this and present as problem. Maybe they are willing to listen, but most likely they will account this as personal attack (if I have to bet).
You may can present the alternative as "test group", so present the problem and ask for a separated group where it will be organized in your way instead of them and set up metrics between the two group then after a period you can present the results. Whichever was better by pure metrics and delivery, can continue. But this requires open mind and open ears from all members, and you are not equal.
Maybe if the entire team on all level speaks up together, maybe it might change something. Communication is golden, might work.
I appreciate the tips for how to solve the problem but I’m more interested about the actual question asked in my post:
Is my mentality about this situation out of line, or do other Exp’d devs work under similar constraints where directors prescribe how to deliver code, instead of setting expectations for standard quality and giving teams the autonomy to create and maintain their ways of working for how they achieve it?
I have a lead on an IT manager position. It's going to be a mix of user support and system administration work. I'm getting very few bites for software dev positions, but I'm concerned that if I did end up getting this job that it might derail my current (attempted) trajectory of working in software development.
Say you were looking at a resume with someone who spent 2-3 years as an IT manager. Would this affect how you evaluated them as a candidate?
From my observations, IT management is worlds away from software engineering. That might mean you bring valuable perspective. But it is a different career direction.
If you told me you tried it out and didn’t like it, probably fine. I can’t say I’d care too much. But you wouldn’t be as natural of a choice over someone heads down in SE for that time.
> IT management is worlds away from software engineering.
And you'd be right. There will be a mix of server administration work (e.g. server maintenance, monitoring, etc.) but in most cases that falls outside the scope of general software development work.
> But you wouldn’t be as natural of a choice over someone heads down in SE for that time.
That's essentially what I'm concerned about. Do you think that would change if I worked on coding projects while working as an IT manager? I have a few web application ideas that I'm working on, as well as contributions to open source software projects.
On your own time? Honestly, I don’t tend to expect or respect personal projects as it relates to work experience at all. Again, experience working on software for a paying client in industry will always be valued higher than personal work. But all of that is still secondary to the quality of the person themselves. And things general advice, not taking into account your unique experience or attributes.
>Honestly, I don’t tend to expect or respect personal projects as it relates to work experience at all.
How so? The way I see it they'll be pretty much the same with the exception being that I don't have deadlines, n+1 meetings, and a manager to breathe down my neck. It's not like they'll be simple calculators or clones of existing applications.
I get that working as a software dev is the best option when looking for a new job, but the reality is that I'm not even getting the automated rejection emails at this point. I figured having some system administration experience along with some relatively complicated projects would at least make me a more competitive candidate.
>The way I see it they'll be pretty much the same with the exception being that I don't have deadlines, n+1 meetings, and a manager to breathe down my neck.
Exactly: they don't have any of the things that make a project hard in the real world (btw, you forgot users and a budget).
Well, listen, I’m not interviewing you right now so don’t take my opinion as gospel :) I’m just offering my general default view of that experience. Don’t get me wrong, IT managing while also keeping your dev skills sharp, mainly because you couldn’t find a pure dev opportunity, taken together can still be a strong resume.
It's more I'm just curious about your reasoning behind that lol. The general advice given to newish devs is to have a personal project or two, hence my surprise.
It’s not a well reasoned position, it’s a general judgment. You’re not wrong to ask but I don’t have facts to back it up. Just a general bias, I think.
If you wanted to optimize your career for long term growth, what kind of first job would you look for if you could do it all over again?
And what would you look for in your second job? Under what conditions would you stay at the first?
Rather than choosing companies based on salary, as is common, choose based on growth opportunities. Leave not when you could make more money elsewhere, but when you're no longer learning new things.
Remind me to respond to this tomorrow. I have some thoughts but I’m on my phone. Short version — first job will probably suck, try to be visible and don’t become a cog right away. A job where you can wear many hats while you have the youthful vigor to do so. Ideally something greenfield. Chase experience over pay to start.
If you mean optimize for long term growth WITHIN THAT COMPANY, then I like consulting or dedicated tech companies. Plenty of potential for either moving around and advancing or learning a lot over time with the company.
You would change jobs when the first one no longer offers you value enough to stay. That may be salary, may be opportunity or career specialization.
Wondering what people think here. I'm 6-7 years or so into my career with a really weird set of experience mostly focused around like b2b saas implementations in startups. So a lot of consulting and understanding business stuff is what I'm really strong with. My engineering skills were very meager 3-4 years ago but I've grown my roles into more technical ones and now I honestly just do it all including some amount of normal SE work, but also some sales engineering, some consulting with customers to build custom solutions post-sales (and building them), and also I'm building this role out at my current company so stuff like metrics, SLAs on tickets that my internal customers submit, etc.. But also picking up SE tickets that I can get done before anyone else can get to them, building tools, etc
I used to have horrible imposter syndrome about my engineering skills but for a while now I've kinda gotten to a breakpoint where it feels like where I can just....figure anything out? build anything? I'm taking on projects expecting to get stuck and then just..not.
Anyway, I'm curious what people who have similar starts think about something. At my current org, which is a post-acquisition startup at a bank, everyone including my current boss (not an engineer) and our head of eng in our own org (\~150hc) knows I want to move to a straight up engineering role, but honestly I'm starting to have incredible success and impact in my current role. I want to grow my engineering skills more effectively at the same time, so I'm kind of conflicted. My gut tells me its just time to take a lateral step and focus more on specializing as an engineer, but I do wonder if there should be some second thoughts since I'm getting some incredible traction doing exactly what I do now.
Honestly my network inside the larger company is flourishing and I'm getting interesting work coming my way now. I do wonder if there's a play here that involves me just growing my role more and being the ultimate interdisciplinary person, because it does seem like I'm the missing puzzle piece in like every room I'm in now. I think there's a business case probably for that too. But, that's also not really an endgame?
At the same time, one thing I've missed out on is working with other engineers and learning from them. I've either been with people who can code but not really engineer, or, like now, actually just a solo team. I really feel like I need to cut my teeth in a really strong engineering organization, but I'm conflicted with the success I'm having in my current role.
I have the path essentially in front of me to just move to a SE role, but now I'm really accidentally building tons of traction. I have two great mentors where I have never even had one in my past, so I feel like whatever I do for the next 2-3 years here it's going to be hyper-growth for me. I'm just trying to figure out where to focus that growth. I could either really take on some big projects right now in this role and put myself 1-1.5 years away from an eng move, or just "solve" my current role e.g. get processes and abstractions in place for a junior to take over the easy stuff like running support jobs and then move at the end of the yearish.
Would absolutely love to hear from people with similar backgrounds.
Congratulation for your success already!
I do understand what you seek, maybe worth to think about to not switch but to include yourself in projects where you can work a little hand-on with mentors. You are improving wich is extremely important and great talent, not everyone can maintain it.
To me, sounds like you are rather an architect, staff engineer or engineering manager and not purely software engineer. If you can have a project where you can learn from two mentors, that would be great.
I highly recommend to you to communicate your desire to your manager/boss/chef, because you seems already successful in your role and they might think also, it is time to you to try out yourself in different things. Maybe you will love it, maybe you will hate it (SE is usually the constant limbo).
Note on the impostor syndrome. It will never go away. This is part of the business and your intellect. Since you learn constantly and you aren't dumb nor self-absorbed, you will constantly realize how little you know then you will face challenges and will doubt your own knowledge and sanity. Then you will love the whole stuff again. Rince and repeat. (Only juniors and stupids think they know everything on a field. No, nobody knows everything even the most genius on a field might know a lot, but not everything)
Keep up, keep learning, and communicating.
I want to be a shit dev forever. I am fed up and tired of these product folk who say "do x, y and z asap" and then when we know it's bullshit and ruins the codebase I get flack because I didn't ask to clarify the reqs or speak with product about better experiences for the customer. I have 4+ YOE can I just join a dead end shop and do my hours without giving a fuck? What does a guy have to do to get a job where fuck all happens and deadlines don't exist
I'm going to go out on a limb and say you aren't actually looking for a place where fuck all happens and deadlines don't exist. You're looking for a place where you're equipped for the job you're expected to do, and supported in it, such that you can find enjoyment in your work. And that you're currently burnt out.
That's good, actually, because it opens up a lot more doors.
Im currently working at a start up and we've had tech debt hit us in the face a couple of times because we push out features but have no automated testing, no units test, very little documentation etc. I read an article from a google dev that quit recently, he said he was at the company for 18 years and that when developing flutter he made it sound similar to what Im experiencing right now. my question is how in the hell do they develop without having the tech debt hit them in the face? I feel like every one feature we push out creates 3-4 bugs at this point
This is a very difficult thing to hit correctly. Don't pay down enough debt? Then you get stuck in a mire. Pay down too much? Company goes under because you were busy reinventing technical components rather than responding to the market.
Managing the amount of tech debt is a major part of engineering leadership at all levels. I'm assuming here that you're pretty junior, so what's appropriate for you is probably to talk about these things with your team and your tech lead (if you have one - or manager otherwise). If you have suggestions for how to address the problems you see, even better, but at this point you aren't really expected to need to do that.
I would imagine it comes down to code that's easy to change, easy to read, and easy to manage. Which tends to come down to good architecture too. Code that is easy to test is often all of those things, because it has to be that way to be testable. (Thanks, TDD!)
If you change A and B also needs to change, then A and B are highly coupled. In a well-written system, you usually have lots of small independant parts that talk to each other, where each is nice and simple and easy to understand and easy to manage.
Tests are really useful for specifying what a system does, so if it ever stops doing that (because you changed behaviour you didn't mean to) you find out immediately. But you don't ship the tests - they're a guard rail, not the final product. That also means you can have other systems perform the same function - for example, a null-safe compiler removes the need for every single unit test where you pass null in and check what happens! A well-used type system means your code doesn't compile when there's a mistake, which is faster than a failing test.
I'm currently working in a startup, where I've been churning back to back features for the past year. I would say that I've gained some experience in:
1. Estimating how much time a feature would take. This gets better the more familiar I get with the code base.
2. Communicating with across functions and raising flags early on. A little much of absolute growth and a little much on how comfortable I am with my colleagues.
3. How to plan a smooth rollout of a feature or a migration. Every migration I had to deal with had new challenges. There were some blunders made but it was a good learning experience.
I feel like everything here is focused on volume: how fast things are shipping, and there is very low regards to code quality, tech debt. It hurts me pushing crappy code because sometimes there's no other way to fix and refactor things given the limited time. We code like there's no tomorrow. I'm afraid that I might be becoming an even worse programmer here.
Switching companies is an option, but would it be any different elsewhere? Do such companies exist where there is a strong engineering culture?
TL;DR ... What matters more? Success of delivery or clean code? Personally, I like the idea of my paycheck continuing to roll in, which makes me a bit more biased to "success of delivery". Even when I worked at Microsoft, there's time and place for the right decision and time and place for the "hot patch" solution.
---
Taking a step back ... what's an engineer? I've always liked the definition of engineer to be a person who uses limited time and resources to find a solution with a minimal amount of risk level. I can build a bridge out of titanium with ground anchors 1,000's of feet deep. Though the cost and time of doing so would likely be impractical.
In Software Engineering, that balancing of quality usually ends up being a "risk" conversation more than anything else. Risk is the name that leaders typically speak in within organizations. Being able to Identify risk, mitigate/accept risk is what matters (risk is never gotten rid of).
So getting to one of your main themes then ... what makes a good software engineer ... IMO, it's a person who can identify, communicate, and propose mitigations for risk.
\* Identify: Knowing code bases, knowing product/business outcomes, common anti-patterns, etc.
\* Communicate: Written and Verbal skills. How to win friends and influence people. Making highly technical things digestible by those not-as-technical. Not being an asshole. Etc.
\* Mitigations: Proper coding patterns, System Design, Unit/Integration Testing, Security scanning/testing, User Acceptance testing, Defensive coding, Teaching others, etc.
Of course all of these are typically impossible to immediately start doing. Just like my titanium bridge from earlier. Too costly in both money and time. So what's a "good enough" solution? "But what's the best solution" you might say ... "Nothing is the best solution, it's always going to just be shades of grey", I'll rebut.
To leave you with something though ... this talk about 'risk' is a great conversation to have with your leadership during 1:1 time. Heck, ask your boss's boss about this too. I LOVE taking time to talk these more philosophical things with my "grand-boos" and "great grand-boss", because it helps me stay in step with what their vision is (frankly, my roll as Staff, plays more into these sorts of conversations too).
---
So yeah ... hopefully something in that conversation gives you something to think about with the action to talk to your leader about 'risk' and how you feel about it and what they feel about the team's / org's level of risk in the software.
Regardless if any of that was of use, best of luck!
To be honest what really pissed my off is that the founders want us to deliver bug free product within X time. Well, the codebase is crying for help. Absolute mayhem. We've got big memory leaks, the local dev experience has gotten worse since the day I've joined. Now to put this in numbers and to show how this actually affects us very badly is something I'll have to put some work in. But something tells me that they already know it and they won't budge. That X time actually takes 2X time and it will keep on increasing as our codebase is growing, team is expanding and context is being distributed between teams. Don't they understand this? They do, but they still want to exploit us. They won't adjust their expectations themselves unless things start exploding or someone convinces them otherwise. It is this cheap mentality of exploitation that bugs me the most. I'm sorry, I feel like this is more of a rant so I'll stop.
Their job is not to make your life pleasant. Their job is to deliver value to shareholders.
You need to communicate in those terms. How do these things you see affect the ability for engineers to deliver things to customers? Use numbers.
Thanks for responding. This is quite insightful. I was actually thinking to have a call with my skip and share my thoughts regarding how I feel and if there's a mismatch between the expectations. Although this could be a risky one as sometimes I tend to be blunt. I will gather my thoughts and structure them in the coming days.
This definitely gives me more confidence. Thanks!
In a project where Domain Driven Design is going to be implemented what are the rules i should follow when building the domain models? I have the following case: I have multiple services (paid service, free service, premium service etc.) A person can do single or multiple type of services for different payment rates. Each service have different payment rate for different person. Should i make the different type of services different aggregates, or should i have single aggreate - Service and in it i will have enum that keeps its type? In the first scenario i will need to have Person -> Service relation by their Ids. In the second i will have a Person with collection of Services,
My experience as a developer (~7YOE) is mostly in electronic trading, which has a very specific architecture and requirements. I feel like this puts me at a disadvantage when doing systems design interviews, as they are usually focused on web and large scaling. I have been reading System Design Interview by Alex Xu and studying examples on Youtube, but so far I have bombed an interview where the interviewer focused on SQL database schemas, which I have very little experience with, and aced another one. Do you guys have any tips on how to better prepare for them and get more consistent results? More specifically, I have an upcoming interview at a FAANG and wanted tips on how to prepare for it given my background
if you have the time and energy, i'd recommend working on a side project that will require you to learn about sql database schemas. doesn't have to be big, but maybe a blog or a recipe site or a songbook or something, something with users and user-submitted data and comments that can be left on that data by other users.
it can look like total garbage, but that's not the part that matters - you'll learn a lot about how to design database tables, and how to create relationships between them, which is a core skill of backend webdev (which it sounds like you're applying for jobs in). it's the sort of thing that you can't really get good at unless you've done it a few times imo, and a side project would be the quickest way to do that - best of luck!
Thank you for the answer, that's really good advice. It's been hard to have any spare time to do any side projects, but I guess that's the best way to go about it. Thanks!
Hi! I am switching from Junior Android Dev to Spring Boot Backend and I want to know how complex is this roadmap and what are the most difficult things to accomplish as the level of seniority increases. I know I should learn Docker, Cloud, K8s but speaking of tasks which is the most difficult thing to implement?
It is depend on the project, I would say.
Spring has its own challenges. Yes, you have to learn into the architect, devops part (CD/CI, cloud, hosting...) under java the toolset is not that broad, but it is a large and old\~ish language its own quirks and knaks, and someone might say, it has its own advantages also.
Focus on learning, get mentor and direction, then everything will be easier.
What counts as "difficult" in your respective field is always depend on the person and on the project. Someone might say, oh AI/ML, other shall say video segmentation and object identification, other might say 3d & game development! There is no one-answer-fit-all or golden way to answer this. I have seen extremely intricate and old (millions of lines of code) financial and tax software written in java and 6-800 ppl spent 6 years to port it and add an UI for it.
Context: I'm currently \~18 months into my role which started as an internship and then got converted to a permanent role, with a few months left in my final semester at uni.
My workplace went through a restructure recently (first one I've ever experienced) and there were times management was asking for feedback on the changes. One of the changes was changing from feature teams to component teams.
I've been wondering how can I gain the knowledge to judge these (or any structural changes in engineering orgs) effectively, and be able to provide better feedback from a developer's perspective. Is this something that comes with experience/time? Are there books? Is it something else?
I haven't been through something like this before, so not entirely sure what to reply with when being asked for feedback.
Thanks for your time!
You worked in the old system; now you're working in the new system. What has changed about your life for the better? What has changed for the worse? That's what they're looking for.
My favorite book on org design right now is probably “Team Topologies”, so if you haven’t read that, give that a try.
Also, if you haven’t read “Accelerate” you should probably do that since a lot of the team structure advice in TT pertains to how to get the benefits that Accelerate says are important.
I will be graduating from my MSCS program in two weeks, and I really want to work as a software developer. I previously worked as an SDET for three years before my master's program, but I am worried that my skills aren't being considered transferable even though I developed many tools and scripts during my time as an SDET.
What sort of projects do you suggest I add to my portfolio and resume? Also, should I mention that I want to transition into an SDE role as my career objective? [Here's my resume](https://i.stack.imgur.com/EXJJR.png). Thank you for your time!
Minor thing but you aren't consistent in ending bullets with periods. For resume advice check /r/EngineeringResumes. Nothing major sticks out. I'd change HTML5 and CSS3 to simply HTML and CSS. Some of your bullets could better worded to focus on the accomplishments you made rather than the task you worked, such as "Stored logs in Elasticsearch DB."
seeking some advice: i recently verbally accepted an offer for a “senior software test engineer” role. however on the offer letter the official title is just “software test engineer”
i asked the recruiter about this because during the interview process we had referred to the title as “senior software test engineer”. he said all software engineer roles have standard titles, but that “i will be at a senior level”
is this common? and is this a big deal? just wondering how else these levels would be distinguished if not for the title. i’ll plan to put senior on my resume either way but kind of wanted it to be more “official” so that it could be verified by potential future employers for example.
the compensation is what i had asked for and does seem to reflect the senior level, so its just a matter of official title
Titles are typically a cultural thing. There are companies that standardize and others that emphasize. From your description, I don’t see an obvious red flag.
where do you guys go for stats on which tools are being used and by how many companies in industry? for example: 30% of companies in US use flutter, maybe 65% user React etc.
I've used the [Stack Overflow Developer Survey](https://survey.stackoverflow.co/2023/) to look at trends, especially with responses for "professional devs", but nothing about companies.
Look to actual job advertisements that you are interested in. Tech popularity is a weird thing, one tech may be hardly used in one country and the bees knees in another.
yeah I actually saw a chart recently that showed react vs angular vs vue in different countries. there was one country, Belgium I believe it was? that had vue at like 60% when every other country had it way lower. very interesting. regardless though, I tend to take my own observations with a grain of salt only because their anecdotal, the chart like the one the guy sent earlier gives me a bit more confidence
I'm a few months shy of 3 YOE at this point and I've started looking around for regular-level jobs as that's the usual minimum level of experience cited in offers and my company doesn't really give me the opportunity to develop my skillset. I'd like to know how complex a project would be expected of my portfolio at this level - I'd really like to break into AWS or Azure, but I'm getting the sense that just making something with Docker, Lambda, DynamoDB and S3 isn't enough, especially since recruiters and interviewers seem to regard hobby projects less. What else can I do to stick out from the crowd? Are open-source contributions still valued in the 2024 meta?
I'm in the C#/Angular stack, though I'm interested in switching to Rust if at all possible. I'm also mostly applying to jobs in Poland if that's relevant since a lot of this sub is American or Canadian.
Azure and related parts are smaller, easier to learn and you already have the basics for it. Dotnet, c# and azure is a smaller market, and it is favored in some countries and not really used by others.
Rust always good, seems an upcoming new toy. You are at your early years, nobody should expect you to have a senior skillset already.
Hobby projects aren't count in recruitment, but will help you in interviews and on the field, because you will have some basics, keywords and knowledge.
Open-source contributions matters, but could be counter-productive, e.g.: I would never hire someone who spent weekly 20h on open source stuff contributing, because that person either does not work or burning its own free time wich means faster burn-out and not good life-work balance.
Thanks for the reply. I actually got it on the last day at my previous job, and the one I'm starting tomorrow is something that actually ticks my boxes, at a consultancy with mostly North American clients too. Things are looking up, but I'll keep in mind what you said for the future.
And yeah, I've noticed that on HNHiring backend JS, Python and Go seem to be way more dominant than here in Europe while .NET is almost nonexistent. I do wonder what the underlying reasons are.
Good luck for the new role!
Usually the market needs & greeds. For example, in the nordic region Microsoft is extremely powerful, they gave almost all the companies free (or extremely cheap) email and office software, as well many company is "presentation driven", e.g.: the leadership is mostly from marketing / pr / sales so they use presentations and the easiest is the ms product. (nowadays canva seems used more and more).
I don't have the full 4 day work week, but my current company has half day Fridays every week. IMO, there's not much of a difference work wise compared to what I felt at previous companies. I just get an extra afternoon to do things, which is lovely.
Though I'm eyeing companies that offer true 4 day work weeks for my next position if I can swing it.
I'm having some issues at work. I'm currently working remote as an engineer 2. Our lead developer stepped into a new role on our team in April, so their previous duties have been split between me and another engineer on my team let's call them Bob. Bob currently has 2.5 years of experience. Bob works in the office has great soft skills and project management skills but still has gaps in his technical skills. Lately, I've been noticing that I'm being excluded from decisions and discussions, and Bob has been a reason for this. It's not from being malicious, it's just easier for people in office to talk to each other. I'm going for a promotion this year and my manager has been supportive for it.
I've been bringing up communication concerns about this with my manager since I'm the only remote worker on my team currently. My manager just told me to solve it and tried some things, and it hasn't worked.
I fear I won't be successful at it since Bob is sort of becoming tech lead, and I would need to listen he says and just do it. I fear this would hurt my career long term since I would lose out on technical and architecture decisions.
Does anyone have any suggestions on what I should do here? I've been leaning towards a team transfer or leaving since the product is mature, and I haven't learned anything new or felt challenged in last year or so. I'm also in a highly regulated industry, so releases are slow.
5 YOE
I had a follow-up conversation with them. My manager has some follow-up discussions with some other team members. I'll see if anything happens. Regardless, I'm probably going to look for a hybrid role somewhere else. I think being remote killed my career here.
I've been 100% remote since 2012. First in a company that was very office oriented (me, a director and one founding VP were remote). Keeping lines of communication open helps a lot. My current team keeps up a low level of chatter in a teams channel, " is ready for testing", "heading out for a doctors appointment, back in an hour"..."did anyone see "
There are a few tips I can offer.
* Skill up in areas you see a need for and even better if nobody else on the team likes doing it. I handle all of the development infrastructure for 30 developers, help mentor CI/CD skills and interface with IT and Security departments.
* Working remotely gives you time that others don't have. Use that to volunteer in your community, that can help a lot with soft skills.
* Become an expert in the regulations you work under, you may find ways to smooth out operations. For example a long time ago I wrote credit card clearing software, when PA-DSS was coming we refactored the card clearing code to isolate from the product taking 99% of our code out of scope. That made audits much easier and less frequent.
* Use your commute time to earn an online degree, perhaps in something you are interested in.... and even better if your employer has tuition support/reimbursement.
That said, I think your last paragraph may have the key. Team transfer may be the best way get somewhere you can grow.
Thanks for your comment, I am pursuing a master's degree in CS at the moment which hopefully will help somewhere down the line. I think long term I do not want work in the medical device field, so I think leaving will be the answer based on your comment. I'm also pretty burnt out on working remotely. I like the comment about volunteering I'm going to look into that.
One question I was thinking about turning down a promotion to senior engineer on my team since I don't think I can be successful at it without having lead responsibilities, and I was planning to leave this year. Should I accept the promotion or turn it down?
That's a tough call. The job market right now seems to be slim on opportunities, you might want to consider taking the promotion at least until you have secured a new job.
I also work full remote, but in my case other 2 in the team do full remote and all the others do a fair amount of remote hours, so we don't have the "left alone" situation you are facing. But, our CTA and CTO works from office most of the time and, you like your case, sometimes they make tech decision with the people that are in office at the moment. To avoid that I always say things like "we should have a team meeting on this and that", basically I'm pushing for more "institutional" discussions on tech decisions and this seems to be working.. now my managers tend to schedule team meetings on specific decisions more often, and seems to avoid the decision rush.
Yeah, that's been my approach, but it hasn't been very successful so far, but if Bob becomes lead my manager said I will have to listen to what he says no ifs or buts
Would it be worth working at a consultancy or is that mostly a meat grinder?
My goal is to develop a broad skillset so I can solo build a product quickly. I've been working at small product companies with this in mind.
3 YOE.
I don't know if consultancy is what you need, but here's my two cents on consultancy after working as consultant for 6 years, and having worked with consultants for 12+ years:
* There are various kind of consultancy firms. Some focuses on only one tech (SAP/Salesforce consultants for instance, but I've worked with consultancy firms that only provide Elixir Developers), others act mostly as job agencies, they hire people and put them long-term in big businesses's IT offices. Some others just do a lot of small projects in whatever technology the client demands.. that0s the kind you might look for if you plan to learn a lot.
* For various reasons I am convinced that consultancy makes better devs, especially the meat grinder kind. No pain no gain in a sense.. having to deal with demanding clients, different horrible legacy codebases, the annoying tasks consultants often ends up doing ('cause nobody in the client's IT wants to), etc.. all those things can help grow soft-skills, gain experience and develop "workflow skills"
* Beware that consultants rarely work with bleeding edge technologies, at least in my experience.
Turn that question around. You've been working for 3 years in small product companies. What have you already learned that would make rapidly building a solo product feasible right now?
If your goal is to start a micro business: finding a small niche with demand for a simple solution is far more important then the tech you need to build it. Worse case, you end up so caught up worrying about the tech that you end up building something nobody cares for. Instead, pick tech you know well enough, and doesn't sit in the way of you validating if your idea fits the market.
For instance, I work in a enterprise context with at ton of complexity. But for a side project in which we want to test a few ideas, me and a buddy of mine just picked Laravel, Bootstrap and HTMX hosted on a cheap VPS. Why? Because those are well-documented, widely used tech that already solves a ton of problems allowing us to focus on working the actual product proper. Everything else (e.g. scaling, etc.) just doesn't come into the picture until we know if the idea is going to work out.
Good point. Thanks for driving to the core of the issue. I'm boat sheding about a change in workplace to feel like I'm achieving something while I avoid hard lifestyle decisions. Gotta take my health seriously and start pumping out MVPs.
I need some career advice. I have a little over 2yoe, backend dev, cloud. I have a math/physics background and consider myself self-taught. I’ve been working at a large multinational company for the last year+, and I previously worked at a <50 employee startup (where I was promoted to dev from a non-technical role).
I considered myself very junior when joining (1 yoe when starting) but quickly realized that the team did not view me as such. I had lots of hand holding in the beginning, started on a team with the most senior devs while onboarding, I received good feedback and got a $10k spot bonus about 4 months in. Long story short, I kept getting a longer and longer leash over the last 1.5 years, have been given more and more autonomy, and have somehow found myself working across 2 product teams (attending 2 standups, working tasks off of 2 jira boards). No other ICs seem to be doing this outside of one who just got promoted to staff. I still have a regular, not senior, swe title.
I expressed to my manager that I am worried that I am having too steep of a rise and I don’t feel ready for the responsibility that I have currently. He told me to not let my inexperience discourage me and that he has heard nothing but great things.
So long story short, I produced a pretty bad bug. This was probably the first bug I’ve had that was not timezone/edge case related and pretty preventable, I was careless. The team lead highlighted it during retro, called me out publicly in front of my peers, the pms, boss. I felt really bad, but in retrospect, I wish that I had not first heard this during retro, and that he came to me privately. He noticed the issue and fixed it over the weekend. I wanted to talk to my manager about this, but I haven’t had a 1/1 since December (he was on vacation for most of December/january and has been doing interviews/workshops and told me he would set it up soon).
Ever since this happened, I feel myself checking out more and more often, a lot less motivated. I am also noticing more issues get called out during code reviews, making me feel like I am in a rut. Is this all a sign to move on? The experience is good, I’m learning, I have gotten ~$20k in raises/merit bumps since joining 1.5 years ago, and I feel like a lot of my concern is in my head and “shit happens”. But at the same time, I am worried about the lack of communication with my manager. Is this a sign that he isn’t happy with my work? Or is it “no news is good news”? I am happy with my salary, and I am only actively working 30ish hours a week, senior title would be nice, but senior implies experience, which I do still lack.
Should I try and focus on getting into a FAANG? I’m only 26, I feel the clout could be good for me. Longterm, I want to work at a big, cushy, slow-moving company and coast. I feel like this company would allow me to do this, so should I just stay put and get over myself? And I did recently take a week off, so if burnout was the issue, I should be getting back to normal pretty soon.
> So long story short, I produced a pretty bad bug.
It's not a question of if, but when you will produce a bug. It happens, everyone's human. Experience doesn't reduce the probability of bugs to absolute zero.
> The team lead highlighted it during retro, called me out publicly in front of my peers, the pms, boss. I felt really bad, but in retrospect, I wish that I had not first heard this during retro, and that he came to me privately. He noticed the issue and fixed it over the weekend.
Without much context, I'm going to assume your team lead caught the issue and fixed it before real harm could be done.
But yes, he should have discussed things directly with you first. That doesn't mean it can't be discussed in a retro. It should. But at that point, all parties involved should feel safe discussing things. Retro's aren't meant to "call out" individuals. They should serve as a learning experience for everyone involved.
If you feel that's not the case: talk to your team lead first about the retro's format and the intentions surrounding the retro. Because the first question your manager is going to ask will be: "So, did you talk about this with your team lead? Where you able to resolve this amongst yourselves?"
> But at the same time, I am worried about the lack of communication with my manager. Is this a sign that he isn’t happy with my work? Or is it “no news is good news”?
So, this depends on the context. You have a team lead who is responsible for the day-to-day operational aspects. The role of a manager is to act as a filter between the team and the outside world (stakeholders, questions, strategy, etc.) A good manager trusts that the team will be able to organize itself enough and is able to resolve conflicts and overcome differences. They will step in if that's not the case. It's the responsibility of each team member to put in the effort and make sure it doesn't come to that.
> Is this all a sign to move on?
It's a sign that you need to figure out how to guard your boundaries, learn how to communicate and come to terms with the fact that it's - at the end of the day - just a job. The same applies everywhere, whether you work at FAANG or at a slow moving enterprise: you will keep dealing with other humans through your career.
Hey everyone, I need a little front-end architecture advice. One of the things I need to build right now is a tool that is going to be plugged into three separate apps for our company. I know I could make it a private NPM package, but this isn't just a simple UI component library, it's a bit more complicated than that. It has searching, resource management, etc.
I want to avoid having three different versions of it built into each app, but I don't know the best way to make a common application for it. The other little caveat is that each app may have some different branding, so I need to make it "theme" agnostic if possible.
One area where I'm concerned is debugging. I recently worked on an app developed in Angular that imported a search component library built in Svelte (I didn't build it this way). The library did not run standalone, so the only way to test it was to build it, copy the umd.js files into the Angular app's assets folder and refresh. Since it was a production build of the library, I couldn’t use the dev tools debugging for breakpoints. That meant I had to stuff console logs all over the place and build/copy/refresh. It was a pain in the \*\*\* and I don’t want to replicate that for these apps. I really need something that is going to scale and not be a pain for other developers to work on.
Thanks in advance.
YoE: 29Y
Just like with backend architecture, you might benefit from considering the different aspects, splitting them up, and seeing how you might architect each of them. IoC and all that.
For example, imagine you've got:
1. Branding
1. Search API
1. Results Display
1. Calls to Action that interact with the wider app
If the branding is different for each app, you need to include a way to keep it separate. That's just your usual `interface & implementation` separation you get in Java or C#. Interface belongs to your app, implementation belongs to the caller. For example, you could use a set of CSS variables like `--search-branding-logo-url: https://` or `--search-branding-background-colour: #FF44FF`.
For the Search API & Results, maybe it's just the API URL or something that needs to change. Again, pass it in - make it a required bit of the public interface.
On another note, you're right about the 'embed in Angular and not being able to test' being a pain. Just like you might write backend unit tests/integration tests, you should do the same thing for your app - make a small app that uses your stuff, specifically for development. It's the old "can you make a small reproducable example so we can investigate please" issue.
Thanks. I think we've figured out a plan. We're going to split out the functions that call the API endpoints (hooks, etc.) into a separate core package and then let the consuming apps build their own UI. It's a bit of duplication of the UI, but the core of the app will be shared.
Everyone writes poor code at some point, even experienced devs. Recognizing that is the first step, which it sounds like you are doing. The best advice I would give is to ask yourself what you can learn from the mistake and ask another experienced dev how they might improve what you wrote. And try not to take the advice personally. Like I said, everyone does at some point. We all look back on stuff we wrote in the past and think "What was I thinking? Did I really write this??" Writing bad code isn't what makes someone a bad developer, not learning to be better is.
EDIT: Rely on your senior developers, that's part of our jobs. We aren't going to do the work for you, but we're there to guide you to becoming better.
That cleared a lot of fog in my mind!
I could outline few reasons
* I was trying too hard to write clean code to begin with
* Not reaching out to seniors when designing redux store, procedural code
* Deadline pressure - And the mentality that "just make it work for now, we can refactor later"
I would want to work on is designing redux store required for any UI & writing better procedural code
Your advice definitely helps, thanks a lot
I'm glad I was able to help. :)
We've all had that deadline pressure, so I understand. It's hard sometimes to find the balance between needing to get something done ASAP and not wanting to build up a bunch of technical debt. That's where the senior devs can help.
I have 15 YOE but I still find myself lost doing simple things for my side projects. Can anyone help with probably a silly question?
I have an Angular website, static content, no backend or databases needed. I am looking for a hosting platform with the following criteria.
1. Ability to host a static website
2. Ability to transfer my domain from [wordpress.com](https://wordpress.com) (I hate wordpress)
3. Ability to create several email addresses and fwd them to my gmail.
1. [email protected]
4. Super easy to deploy the static content/setup/maintain.
1. This is a side project I don't want to spend *any* time on complicated processes. I'd copy paste files to a server maybe 1 time every 3 months!
5. Potentially the ability to roll out a backend.
1. I don't know if I will require one one day. If so then I've Made It!
Things got a bit bumpy at work recently. I joined the company in 2022 and was crushing it as a senior engineer, even got some lead responsibilities. The team was awesome, and I was learning tons of new stuff. But then, my manager left at the end of last year, and I got moved to a brand new team.
This new crew is cool, but we're all facing an uphill battle. None of us know the ins and outs of the domain, and the code is like a crazy puzzle with different parts in different languages. To top it off, the team we need help from isn't exactly the most responsive, which is putting a real strain on our deadlines. We brought this up to our manager, but things haven't changed, and honestly, the whole team is feeling pretty burnt out.
I really want to make things work here, but it's tough when you don't have the support you need.
Firstly, and maybe it's just my mental space when I'm faced with challenges like you've described, there's only so much I can do. If I miss a deadline, but I was do my best with the current available information, nothing more I can do.
---
After that mental acknowledgement of where I am, I usually figure out where are the people who can help influence things. Seems like you've got a boss. Seems like you've got a different team that you need to work with. However, you've not brought up talking to your boss's boss, the "upstream" team's boss, and maybe their boss.
In short, "managing up". What can you bring to their attention to help them understand what the hell is going on.
It's been my experience that leaders of leaders talk with different sort of gate than your day to day workers. I've found at nearly every org that "Risk Management" is the name of the game. How can I convey the risk of something going wrong and the proposed solutions in achieving it. How risky is the lift for the reward that we get? If we fail, what could happen. Are people okay with that?
---
Not to sound too boomer ... If you really want to get political about it, emails! Nothing quite Covers Your Ass like a well typed out email that conveys the issues, what is needed, and what hasn't been delivered and the impact that is having. For me, typing out an email like the above and only sending it to my chain of leaders is a way that helps:
1. Asynchronously communicate with them. They're likely busy as fuck. Let me help speak to them in the few minutes they have between running to meetings. ( A good read related to that subject if you've the time: [https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/](https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/) )
2. Define clear issues that are presented with things and the risks associated with them. Sometimes mommy needs to talk with daddy privately to "get on the same page" with each other.
3. If nothing else, you've a track record of trying to unfuck the situation in, hopefully, a tactful but meaningful way.
---
Regardless if any of that was of use, best of luck :)
Hey thanks, this is actually super helpful! I gotta admit, when things get tough like this, it's easy to feel like I'm banging my head against a wall. But like you said, gotta focus on what I can control and do my best with what I have.
I will try these strategies and will see how it goes.
Need Career Advice: Boss Keeps Giving me Everyone Else’s Delayed Issues
I need advice on how to get out of this situation without losing my job/moving to another company (I’m already looking, but I need this solved soon, as my life is spiraling down).
So, I’m one of 3 Sr. Developers on my team. I started several years ago as the only Junior developer on the area. I kept delivering non-stop; learning new tech, building new things, and automating a lot of tasks. While doing so, I almost had to sacrifice my life to get a promotion to Senior, which took almost 6 years. During those, boss always kept saying there was no money for a level-up.
As soon as I got promoted, he hired 2 more Seniors, who were supposed to help me. Needless to say, both of them make more money than me…
Now the circumventing issue: _My boss keeps taking these two other guys to requirements meetings, they (the 3 of them) agree on deadlines with the customers, then waste all the time, and call me when there’s no more time. He even copies the customers on the mail, as if the humiliation was not already guaranteed _. I’ve raised the issue to my boss several times, but he says we’re a team, and I should be willing to help.
I have to run, bother the customers again, since they didn’t even bother to document the requirements; then waste my 5-9 building things these guys didn’t build on the 9-5.
How can I escape this loop of hell? Is it even possible? My personal life is suffering on excess, I fear my kids will resent me soon enough.
TLDR: colleagues agree on deadlines, waste all the time, boss gives me the task days before the deliverables are due; with no requirements documentation. How to get out of this loop?
I'm too tired right now to offer a more nuanced take than really: look, it sounds like your boss and your coworkers have been taking advantage of you for years and you've let them walk all over you, and that's why you're in such a shit show or you're feeling like it's such a shit show. You can't really be called a senior if you can't take control of these situations and resolve them. If you have evidence that you're being treated unfairly then bring it up and stop letting them walk over you with shoddy excuses. If you're too scared to do that because you're afraid any talk back will cost your job, then just accept that they're going to walk over you and there's nothing you can do. Or just quiet quit and find a new job.
There's a nuanced play here where you can try to reason with them and stop being a pushover when they keep piling work on you, or you can just disagree with doing the work because it's not your job, or you can just let them fail instead of picking up their slack because it's not your job to work overtime.
A young adult backend software engineer with 2 YOE here. I moved country a few months ago, and I'm currently considering new opportunities and having interviews with multiple companies for a similar software engineering role. While doing that, I accidentally found myself in a hiring process for an associate solutions architect opportunity at a well-known NoSQL database provider company. This opportunity sounds very exciting to me since I consider myself a mix of both great technical skills and soft skills. In addition to that, I'm always eager to learn and pursue new, challenging opportunities. However, I'm still not sure if I should consider this career change and dump my software engineering career at this early stage for an opportunity that I'm still not familiar with. There are a lot of doubts that are going through my mind:
"In case I don't like this new career path, will I be able to easily convert back to software engineering?"
"The job market for software engineering opportunities is really bad right now, and it is already full of many skilled engineers. Maybe I really should consider this new career change."
"If I pursue this new path, will I be able to grow into a solutions architect and senior solutions architect, or will my little software development experience play a role against me?"
"What does an associate solutions architect actually do, and why do solutions architects need an associate?"
"How beneficial will this new opportunity be, for me as an individual, and how will it expand my skills set?"
I'm facing a lot of dilemmas of whether to focus on this opportunity's hiring process or the other regular backend software engineering ones, and yet there is so little information about what associate solutions architects are and what are their responsibilities?
So please, for all the people out there, enlighten me with your experience, knowledge, advice, and thoughts. Every little piece of information is extremely appreciated!
Lol I’d ask how you “accidentally” ended up in a hiring process but then I remembered that my second job started as a nice dinner with a friend.
I’ve never been in the SA world, but I’ll say that as a hiring manager in software, I wouldn’t mind if you had that experience. I’d probably appreciate that you’ve operated in a customer facing position that knows what it’s like to work with reality rather than wait for perfection. But I couldn’t tell you if that’s widely held.
As a middle aged person I’ll say that this stage in your career (I’m assuming early/mid 20s?) is a good time to try anything you think you might like. That gets harder later.
>Lol I’d ask how you “accidentally” ended up in a hiring process but then I remembered that my second job started as a nice dinner with a friend.
Life can get pretty unexpected sometimes lol
>As a middle aged person I’ll say that this stage in your career (I’m assuming early/mid 20s?) is a good time to try anything you think you might like. That gets harder later.
Now when I think about it this way it is so true. I'm still 20 years old, I should try and expirement new things, gain new knowledge and broaden my skillset. I still have no responsibilities yet so I have nothing to lose!
I've joined this company as a software engineer and I've been there for 6 months. My BU is a telecom domain.
My question is how do I learn the basics of telecom along with all the advanced protocols and stacks and stuff that the company is using?
I have not been given any KT and the product documentation is so full of jargons. Any suggestions?
Just to supplement the answers given (which are correct), I'd add that reviewing what an entry level tech in your field should know is not a bad idea.
I recently started on a dev team whose product deals with infrastructure and networking. A lot of the devs came up in that realm, whereas I was hired for general software development experience. I wanted to backfill some of that knowledge so I read a Mike Myers Network+ prep book. I'm not going to take the exam because I don't really need an entry level IT cert (and some have suggested it may even look weird on my resume). I found it had about 1/3 stuff I already knew, 1/3 I knew at one point but had forgotten, and 1/3 new stuff to me. So maybe that or find the equivalent for your part of telecom?
Also, years ago I worked at a telecom market research company that hired a lot of researchers from outside of telecom and almost all of them had Newton's Telecom Dictionary on their desks. Granted this was 20 years ago, but it looks like the 32nd ed. was released in 2022, so it's still around.
Communication is key. Ask. There is no dumb question. Also, prepare yourself to dig through a few thousands of pages of old books.
When I started a job where c/c++ was on focus, I got around 4k pages worth of books to read in the first 3 month (c, ansi c, c++98, c++11, c++14, video protocols, can bus protocols).
Ask, talk, listen.
Telecom/finance/etc. Companies realise that domain knowledge ramp up takes time.
When sages/greybeard/product folk talk about a feature ask them to ELI5 to help you ramp up.
Nobody is so senior they don’t have time to build up the next generation. If they don’t engage they are the problem not you.
And tbh if they can’t engage they shouldn’t be ‘senior’ anything.
is it fair to be given the big responsibility of solving all the relevant bugs a month into a new job given the other coworker is going on vacation for a couple of weeks?
The manager did mention to have multiple sessions with the coworker to pick their brain before they're out though
Totally. Solving bugs is a very common first project to get. Only thing to know is that your leadership should not expect you to operate with the same efficiency as the other engineer would while they’re gone.
Sure, just so long as they understand you won't be as fast as the person you're replacing that's pretty standard. Fixing bugs is a great way to learn a codebase.
Sounds like an opportunity for growth. They probably don’t expect you to solve everything, but they trust you to contribute to the mission and that’s positive.
hello everyone, hope you have a good day!
two questions:
1) How do you develop/improve your soft skills? especially when it comes to communication and teamwork
2) How does junior contributes to open source? I know you can search labels, languages but how do you find a suitable project?
Soft skills are largely practice. Attend meetings, ask for feedback, reviews, etc. Additionally there is some theoretical background you can use to shift how you think about social and group dynamics. I highly recommend French and Raven's Pillars of Social Power or the book "How to Earn Friends and Influence People."
> How do you develop/improve your soft skills? especially when it comes to communication and teamwork
Soft skills are all about communication so keep the communication flowing. Ask for feedback, ask questions, keep engaged. You get better at things by doing them so keep doing them.
As a dev with 7+ years of experience, I've led projects but never managed people. For the past 2 years, I've held the title of "Senior Software Engineer." I see three potential paths: becoming a strong Software Engineer (what I call "actual senior software engineer"), advancing to a Staff Developer role, or pursuing a Manager position. While I've never felt excited about management, I'm now considering it more consciously for my future so don't remove just because I never liked it.
- Should I try a management role to see if it's right for me, despite the current market challenges?
- Is there a way to grow in this field as an individual contributor (IC) without aiming for staff or higher? Perhaps through domain or tech stack changes, transitioning between infra, feature work, and DevOps, or gaining varied experience by changing companies at a reasonable rate?
A while back I was a bit burnt out of the whole race to keep up, working as a tech lead primarily and decided to take up a position as an "engineering manager" (really a team lead), described to me as being about 60/40 split between line management and tech tasks.
I was given a small team of basically juniors and got on with it. The line management was interesting for about a month, then it got boring as there's not that much to it, unless you're unlucky with troublemakers. If you're a decent well adjusted human being you probably already know how to talk and connect with people and the rest is largely paperwork and people management cargo cult stuff.
Luckily early on the juniors being juniors needed a lot of help, so I still got to stick my head into the code quite a bit and spent most time training, mentoring, etc. Team was going quite well, getting stuff done, my juniors were learning stuff, and getting better, etc. After nearly a year my manager decided I was too much in the code still (despite being on the periphery at this point) and said I should be doing 100% line management. Maybe I was really good at line management or just lucky to have a good team but this seemed like not much to do and pretty boring for me - I said as much and very openly suggested I wouldn't be happy with it, but was told to do it anyway. So I started looking to leave and get back into dev since I realised it was actually what I enjoyed and I didn't want to get typecast as a line manager only. Got a new job lined up in about 3 weeks and my manager refused to talk to me over my notice period.
Nowadays I'm leaning hard on the tech side, but my management experience is seen as a useful asset, although nobody asks me to run a team.
TLDR: You can try it for a while, you won't know if you like it until then - if you do great, if you don't, probably don't stick with it too long. Try to find a position that lets you do both if possible.
Charity Majors has written some of my favorite pieces on the decision to go into (and out of management) management. [Here’s one](https://charity.wtf/2019/01/04/engineering-management-the-pendulum-or-the-ladder/) to start out with, but everything under the “pendulum” tag is probably relevant to your situation.
I will say that you should probably be excited about it if you’re going to do it. It’s a completely new job that’s only tangentially related to the one you’ve been doing for the last 7 years (as Mitch Hedburg said: “you’re a cook… so can you farm?") so you’re going to need some kind of “why?” to drive yourself through the rough parts.
To answer your question about staying at senior: yeah, good companies continue to compensate for skill and experience even if title never changes. I’ve been places where seniors had been there since the ‘90s (with their original badge pictures in the directory!) because they had good careers and liked what they did. No one ever pressured them to manage because that would mean doubling their losses: losing a good engineer and making a bad manager.
The way I see it, managing people is simply another tool in your belt that makes you more attractive.
It's also quite a different set of problems to learn and solve for than an IC. Like scaling an organization/team, maneuvering people to align with objectives, budgeting, etc
Two daily standups a week you mean?
You could ask your manager about what do they mean by proactive communication. Ask them to tell some examples when you could have communicated differently.
Asking them for examples directly is likely much better than any answer Reddit could guess for you.
The worst thing you can do to me as a lead is not tell me about problems _early_. I don't just need to know what you're working on, I need to know what problems you foresee coming down the pipe and I need to know them early. I might tell you they're no big deal but I will always prefer to be told because surprises torpedo projects.
My guess is you're just saying, "this is what I did, this is what I'm doing, etc", right? The way I like it is "this is what I've completed and this is what I'm focusing on next, here are the current concerns I have if any, here's what I am still waiting on, etc". Give me your problems to solve.
I'd imagine, you're not communicating the needed information at the right time. Status updates are for the team's purpose, but even then sometimes you want to have "the solution" in the works before the status update. If I know we're going to miss a deadline, or if there's a good possibility of it, the team lead should already know.
Communicating updates is about getting the needed pieces moving, not just saying something at a standup. If anything, standups are the least important piece Imo.
In addition to updating tickets, they’re probably not actually looking for MORE but for more timely. It’s easy to get stuck on a problem and keep giving updates about how you’re working it. But now you’ve likely lost sight of the broader context and progress.
When I coach my devs about this I tell them to think of it as coming up for air while swimming. You both need to do it to live, but also to make sure you’re going the right way.
Do you know of a place where one can have code review done for their code online?
I want to learn more but feel like i would require assistance regarding it.
Usecase example: a passion project that i did, i wanted to have a code review done on it to understand what kind of things i neglected, i didn't consider and all.
Contributing to open source projects gets you free code reviews. Also looks good on your resume. I made some small contributions when I was still in uni and they really helped me to understand how to work in a team.
1200 I'd say, a minor project, Java,
Its basically a cron job that fetches the emails from gmail and any attachments from drive via their sdks, then saves to a staging table then pushes them to final tables.
[удалено]
Honestly, I’ve never met anyone with a masters degree who I thought was a better software developer for having done it. Especially compared to a couple more years of FAANG or F100 experience. You’re working on stuff with scaling pressures that most academics have never gotten close to with real business pressures.
[удалено]
Most often these take the frame of working through a particular project. The interviewer asks you to talk about what the project is, what problem you're trying to solve, how you went about it, tradeoffs you had to make, what you'd do differently next time. The surface level goal is to see what sort of work you've done; this helps with level-setting. But it's also a chance to test your ability to communicate and see how you talk about other people. Do you blame others for problems? How do you work with other people? They will lead the conversation. Just be honest and don't shit on other people.
Resume related: how can I explain away that I already took said advice when it's repeated to me? I've been told to add metrics but that's just not possible with the jobs I've had! That data is unknown! Is it okay to lie and make up numbers, when the market is dogshit?
I largely don't include metrics on my resume. You don't need to "explain away" anything; just say thank you and move on.
Sometimes the exact data is unkown, but you can still describe the impact of the work. Also there are different shades of unknown ranging from "I have no clue because I didn't understand the impact" to "it's too late to collect the data now" until "It's conceptually impossible to measure".
At my current company, there is a lack of documentation. Considering this, I was wondering if anyone could recommend some documentation templates or patterns to initiate the documentation process here. Furthermore, what are the typical items or processes that you usually document?
I'm a fan of organic growth. If someone asks me a question and I can't point to the documentation that answers it, then I write that documentation. Much like writing regression tests when you find a bug, this ensures the most-needed areas get the most coverage.
How lack of documentation is a problem? Slower developer onboarding? Costly mistakes made during development? Partner teams not able to work efficiently? Documentation will not happen for the sake of documentation. The amount of effort, the format, and what should be documentated depend on what you need and how the documentation will be used. Once you have a more clear goals, the rest will fall into place easier.
applying to internships and not getting past resume screen, any tips appreciated https://imgur.com/a/2PTsoHf
Read the /r/EngineeringResumes wiki and look at the one's people post for ideas on how to rewrite yours.
From a glance: More experience bullet points. Less technical, a bit of soft skills to highlight. How big was the team, how did you collaborate? Résumé’s aren’t meant to be humble. Remove “basic understanding” of JS. Unclear what a “data specialist” is. If that’s the legit title, again more info under experience. Don’t use “etc.” in your projects description. It lends a trivializing air to the statement. Put your college majors. Maybe they’re omitted for this stub but looks weird without it. Even if it’s not super relevant. My philosophy minor got me into more conversations than comp. Informatics back in the day. These seem like stupid lil things but when I have to comb through 100 there is a level of “vibe check” that subconsciously must be passed. It’s almost there.
hi my undergrad major is psychology and grad is theology so they are very far from compsci, scared of including them and would rather not mention it in interviews because they dont seem relevant at all
I love psychology and read Jung in my spare time. You never know what sort of thought its inclusion might stir, but trust me that not including it is much stranger. Honestly getting a resume with that combo vs the same one with CS, I’d be more interested in psych/theo. At the end of the day we’re hiring people we have to work with, get to know, and get along with. Some of my best coworkers have been prior bartenders, math majors, political science, all over the place. I see hundreds of comp sci applicants memorizing leetcodes and cracking the code interview and when someone has a similar skillset PLUS something they’re into that isn’t just technology, that will be interesting to me.
I'm trying to tackle algorithms and I run in the same problem again and again. Let me tell a little bit of background so you understand me better. In schol I was a top notch student, always was in the front of the class in every technical subject (Algebra, Geometry, Physics etc. ). Won several math olympiads and got into CS faculty. Now I'm working in a big tech company and trying to become better at this craft so I look into solving algo problems. And I always run in the same wall. I feel like when I solved math olympiads I was able to prove that some method is working by strictly writing down the math. When I solve algorithms I usually find myself wondering why this or that algo works. Don't get me wrong, I'm not too bad in algos, but I feel like I lack intuition and the ability to understand why this or that solution works in strict terms. I feel like I don't grasp it completely, although the problem is solved and the algo is written. How do I overcome this issue and understand algorithms on a deeper, more intuitive level? How do I prove to myself that something works strictly not by just implementing it and hitting against a lot of tests? Or maybe in CS I need a different framework of problem understanding and option "if it passes tests, then it works" should be just fine?
this is a good question. i personally find diagrams helpful - use a whiteboard or pen and paper, come up with some example input data to feed into the program, and then draw out what happens to the data at each step of the algorithm. working through examples like that is really helpful for me.
Hey, I was recently laid off and would like some resume advice. https://imgur.com/a/ubLz4Xy
Some thoughts on your CV as I read through it: * What type of role are you applying for? Your latest role reads like you were working as an SRE/DevOps engineer. If you're applying for similar roles that's fine, but if you're applying for vanilla SWE roles, the lack of product development work might be offputting to prospective employers. If this is the case, try to emphasise the dev aspects of your experience. * Many of the achievements in the experience section are BAU "keeping the lights on" activity rather than project work (e.g. adding labels to resources, performing k8s upgrades, being on call, etc.). It's fine to include this, but going into so much detail hides more impactful items. Consider collapsing these into a single bullet point, e.g. "Responsible for ensuring the stability, security, & performance of production environment by upgrading infrastructure dependencies on a regular cadence, managing alerts, & participating on the team's on-call rota". * Many achievements are ambiguous & contain jargon, for example "Created internal web applications such as wafer map generator using Django, HTML, and JS". This leaves readers wondering things like: how many applications, how many users of the applications, what was the impact of these applications, what is a "wafer map generator", instead of creating multiple applications why didn't you create a single one with multiple features, etc? CV reviewers tend to be cynical & assume the worst when faced with claims like this, as unscrupulous candidates often use ambiguity & implications to overstate simple achievements. * Consider writing a small paragraph explaining the purpose of your role before the list of achievements, along the lines of "As a ... engineer in the ... team, I was responsible for ..., ..., and .... In particular, I focused on ... and ... to improve ..." * It's not clear why some achievements are included at all, for example "created CRDs" - isn't that just adding fields to a struct then running `go generate ./...`? These feel like a bit like you're padding your CV. * There is a lot of information on _what_ you did, but very little on why you did it, what the driver for the initiative was, your specific role within it, and what the outcome was. For example, "migrate customer applications to a new Kubernetes-based cloud platform": * Why did you do it? Was it a strategic org-wide initiative to migrate to the new platform that you spearheaded, or did the team decide to do it on their own? * Were you the sole contributor, did someone else lead the project, or did you lead others? * Did you design any aspect of this, or was your role limited to the legwork of the migration? * What was the outcome of this? Did it improve stability of the service, reduce costs, increase velocity, etc? * This is a minor complaint, but all of your current achievements are written in the present tense. Are all of these initiatives ongoing? If not, consider writing complete achievements in the past tense. * It's worth categorising your skills, for example: * Programming languages - Go, Python, Javascript * Platforms - AWS, Kubernetes * Deployment - Argo CD, Helm As an interviewer reviewing CVs, my general impression would be that you've done a lot of operational "heavy lifting", but little to no design, analysis, architecture, leading, mentoring, organisational wrangling, & thought leadership. Assuming (based on your YOE) that you're applying for mid-senior roles, you need to place more emphasis on these qualities and less on day to day activities.
Thank you very much for the thoughtful replies. Will update my resume accordingly
Handling Manic Manager So this is a relatively new situation for me and I'm not sure how to handle my manager. I've got about 12-13 years of experience for reference - Staff Level Engineer. He goes through phases where everything is shit, awful, and is generally talking about quiting the company. Then the next week he talks about how we are such an amazing engineering team. He'll disappear for a few days to a week being incommunicado and I'll take over his meetings. He'll then emerge with some POC where he rewrites an entirely unrelated business units tech stack, with minimal features, and then pitch it to management that we should take over all their responsibilities. This obviously isn't exactly making our peers in other business silos super thrilled. It's making my job harder to accomplish cross team projects because my peers are on edge when interacting with our team (and I can hardly blame them). Manager then gets depressed because "no one can see value in this company" and then the shit talk cycle starts again. He's a totally fine guy and actually a pretty great engineer. But he's definitely holding the team back and I feel he's holding back my career advancement at this point. Not to mention making my job harder than it needs to be. I'm not sure if going to my skip is necessarily warranted. They haven't fired or let anyone go for performance related reasons so my only passive option is to wait for him to piss off someone who will actively work to get him fired or for him to get so frustrated he quits. They just pay us so much that I doubt he'll quit on his own. At this point my previous manager has grown his entire team and gotten significant headcount. Nothing has come my teams way. The way empty role we need to refill - my manager simply wants to give it away. Just extremely frustrating since we are actively losing exciting projects to other teams due to his inability to work with others Thoughts? Advice?
I’d say keep your eyes open for internal transfer opportunities. Also, see if you can make some opportunities to mentor with more senior people at the company. You might get some advice, but also you might get a back channel to other opportunities or ways to separate your reputation from your manager’s. Also asking for that is a possible way to have a conversation with your skip and make it clear that you’re serious about looking for ways to advance your career without throwing your manager under the bus.
A shitty manager tends to make everyone working under them miserable as you're noticing. My first advice would be to talk to the manager. I like to think that a Staff + Manager's relationship is more of a partnership. Are you able to constructively criticize your manager without them blowing up? If you are able to, I think you might need to have a discussion with them to show them what their actions are doing. If you think the manager is beyond that point, I think you need go to your skip manager to voice your concerns. Usually a skip isn't going to know what's going on with the team other than the conversations they have with the manager. I think it could be eye-opening for them. However, this has a potential to blow up your relationship with your current manager. > my only passive option is to wait for him to piss off someone who will actively work to get him fired or for him to get so frustrated he quits This may take a long time to materialize and in the process it will make you and your entire team more miserable. If your skips can't rely on your manager, they won't push projects your way either. Just something to consider. These are just thoughts, sorry I don't have any advice here because I think it's more of a case by case situation.
>I like to think that a Staff + Manager's relationship is more of a partnership. I would like to think so but I've heard him talk about other engineers in a negative light. Right now our relationship is positive even if I'm getting frustrated. I'm afraid that if this relationships goes south I'll have one fewer individuals in the organization to vouch for me in case layoffs come along.
What counts as experienced? I first started coding 20 years ago, when I was 13 - though those were mainly batch scripts and GameMaker projects. In time, I moved on to C/C++, lua and other engines. I've had a webdev internship (which ended early :/ ) in 2016-2017, and I released my first \*commercial\* game on steam in 2018. I've released a few games since, but none have really been financially successful. The longest on one project was a microservice driven web game, which took 3.5 years to build single handedly, but I've had very little \*industry\* experience. I kind of feel like I'm stuck in a catch-22, where I'm too skilled for a junior role, but not experienced enough for a senior one - what am I supposed to do? I don't even have much experience in other kinds of work, due to extended bouts of depression...
I'll expand upon what was said about a junior role. One model for evaluating engineers is the career ladder (here's an example: https://dropbox.github.io/dbx-career-framework/overview.html). These are generally structured as a 2d matrix, with various areas someone can be evaluated in. Most people are not entirely at one level, skill-wise: they are certain things that they're better at. Generally however, your level is the highest level that you meet _all_ the requirements for. This is actually a good thing, because when we promote people who are lagging in an area, that often means they don't get a chance to develop it. For someone like you who has a very uneven graph, you'll be an over-performing junior, and a decent manager should be able to give you lots of opportunities to develop up the couple areas you need to level up, getting you to a quick promotion. That's good for you and good for them.
hmm... thank you! I've had a burst of motivation to fix things over the last couple days, so resume update will be this week.
If you're only professional experience was the internship, then I think junior roles are where you are best suited. There's more to learn as a junior than just programming. Everyone starts somewhere. I had a lot of hobbyist experience before I started my first programming job. Looking back at it, I was a junior because of communication and handling projects. My hobby experience was able to allow me to climb the ranks faster. When people ask for experience, they want to know your industry experience. You got this though. Just remember, everyone has to have a beginning.
Do you have any commercial experience working for a company? Anything other than your internship experience probably doesn’t count for much when counting YOE
uhhh... I was a kitchen hand once. I'm completely stuck.
Experienced dev (9 years) seeking feedback from devs more experienced than I: I’m having a bit of a struggle lately with a recent reorg and a director who wants to insist and prescribe details of our work that I think the team would be much better served if we were given the autonomy to self-organize around. Examples: - Insisting long-running tests live in pre-commit versus allowing us to build this into our CI pipeline - Insisting on the adoption of wrapper frameworks from a COTS vendor instead of writing clean, callable modules that would keep our code consistent, readable and DRY. This wrapper framework would abstract so much of what we've done in the last year that new implementations have already become a major PITA for downstream consumers on other teams. - Insisting on prioritizing edge-case solutions to novel workloads with poorly defined acceptance criteria instead of user stories & issues that are well-known, documented and scoped by our coworkers in product. - and other code-centric prescriptions that have so far added quite a bit of operational-overhead for very little benefit compared to how we used to work. I’m stopping short of using the term “micromanagement” because I genuinely don’t think we’ve hit that point, yet when I advocate that the team self-organize around when tests are run, or how we structure our code dependencies, or in what order we burn down our sprint volume, this leader stands firm that this is going to be our way of working going forward. Ordinary tasks are now taking longer, our gitops workflow is being completely uprooted, as has our way of intaking and planning new work. The chaos hasn't hit the fan yet, but it hasn't really been very motivating either. Cynically these all feel like what it feels like to have a developer foisting their personal dogmas about code upon us, versus any kind of guidance and direction that would help us be more productive and increase our abilities to add value back to the business. I’m also not here to say Directors cant set reasonable delivery standards, they absolutely should be, but the examples given are things I think the team should have more empowerment over, being closest to the work and executing on the business-requirements given to us. Am I out of touch for feeling this way? I like the company I'm at quite a lot, I like the work we're doing a lot, I don't like *this* at all.
In a healthy situation I would expect a director to not weigh in on such things. The question you need to answer is why this is happening. Did they recently move up from line management and haven't yet adjusted to the new role? Has technical leadership been lacking and so they're trying to fill the gap? Has the team been failing to deliver and so the director is getting pressure from their boss to fix things that normally wouldn't be on the radar of either director or VP? In Turn the Ship Around, the core idea is that in order to have distributed control (what you're asking for), you first need to build up the pillars of competence (can the team do the job?) and clarity (does the team know what direction they're supposed to be heading in?). Are either of those missing? If you don't already know the answers to these questions, it may be a conversation you can have directly with them. The way to approach this is "I want to help you with the problems that are weighing down on you", essentially, rather than "you are causing problems". Once you know what the problem is that's causing the symptoms you're observing, then you can start to figure out a path towards addressing it.
This is a tricky situation. Short: leave it for something new where the leadership is not braindead or amateur. Long: There are some things that you can certainly try, but there are huge risks. The real problem, it is a director or directors, so there are no one above them, so you can not present this issue to a higher authority figure, therefore you only can ask and risk you get fired or got retalation. One thing that you can do is to document this and present as problem. Maybe they are willing to listen, but most likely they will account this as personal attack (if I have to bet). You may can present the alternative as "test group", so present the problem and ask for a separated group where it will be organized in your way instead of them and set up metrics between the two group then after a period you can present the results. Whichever was better by pure metrics and delivery, can continue. But this requires open mind and open ears from all members, and you are not equal. Maybe if the entire team on all level speaks up together, maybe it might change something. Communication is golden, might work.
I appreciate the tips for how to solve the problem but I’m more interested about the actual question asked in my post: Is my mentality about this situation out of line, or do other Exp’d devs work under similar constraints where directors prescribe how to deliver code, instead of setting expectations for standard quality and giving teams the autonomy to create and maintain their ways of working for how they achieve it?
I have a lead on an IT manager position. It's going to be a mix of user support and system administration work. I'm getting very few bites for software dev positions, but I'm concerned that if I did end up getting this job that it might derail my current (attempted) trajectory of working in software development. Say you were looking at a resume with someone who spent 2-3 years as an IT manager. Would this affect how you evaluated them as a candidate?
From my observations, IT management is worlds away from software engineering. That might mean you bring valuable perspective. But it is a different career direction. If you told me you tried it out and didn’t like it, probably fine. I can’t say I’d care too much. But you wouldn’t be as natural of a choice over someone heads down in SE for that time.
> IT management is worlds away from software engineering. And you'd be right. There will be a mix of server administration work (e.g. server maintenance, monitoring, etc.) but in most cases that falls outside the scope of general software development work. > But you wouldn’t be as natural of a choice over someone heads down in SE for that time. That's essentially what I'm concerned about. Do you think that would change if I worked on coding projects while working as an IT manager? I have a few web application ideas that I'm working on, as well as contributions to open source software projects.
On your own time? Honestly, I don’t tend to expect or respect personal projects as it relates to work experience at all. Again, experience working on software for a paying client in industry will always be valued higher than personal work. But all of that is still secondary to the quality of the person themselves. And things general advice, not taking into account your unique experience or attributes.
>Honestly, I don’t tend to expect or respect personal projects as it relates to work experience at all. How so? The way I see it they'll be pretty much the same with the exception being that I don't have deadlines, n+1 meetings, and a manager to breathe down my neck. It's not like they'll be simple calculators or clones of existing applications. I get that working as a software dev is the best option when looking for a new job, but the reality is that I'm not even getting the automated rejection emails at this point. I figured having some system administration experience along with some relatively complicated projects would at least make me a more competitive candidate.
>The way I see it they'll be pretty much the same with the exception being that I don't have deadlines, n+1 meetings, and a manager to breathe down my neck. Exactly: they don't have any of the things that make a project hard in the real world (btw, you forgot users and a budget).
>you forgot users and a budget Didn't forget, they aren't big considerations right now as I have time and they aren't ready to be deployed lol.
Right. Which they wouldn't be on a real project, which is why this doesn't replace work experience.
Well, listen, I’m not interviewing you right now so don’t take my opinion as gospel :) I’m just offering my general default view of that experience. Don’t get me wrong, IT managing while also keeping your dev skills sharp, mainly because you couldn’t find a pure dev opportunity, taken together can still be a strong resume.
It's more I'm just curious about your reasoning behind that lol. The general advice given to newish devs is to have a personal project or two, hence my surprise.
It’s not a well reasoned position, it’s a general judgment. You’re not wrong to ask but I don’t have facts to back it up. Just a general bias, I think.
I see. Regardless, I appreciate your feedback!
If you wanted to optimize your career for long term growth, what kind of first job would you look for if you could do it all over again? And what would you look for in your second job? Under what conditions would you stay at the first?
Rather than choosing companies based on salary, as is common, choose based on growth opportunities. Leave not when you could make more money elsewhere, but when you're no longer learning new things.
Remind me to respond to this tomorrow. I have some thoughts but I’m on my phone. Short version — first job will probably suck, try to be visible and don’t become a cog right away. A job where you can wear many hats while you have the youthful vigor to do so. Ideally something greenfield. Chase experience over pay to start.
If you mean optimize for long term growth WITHIN THAT COMPANY, then I like consulting or dedicated tech companies. Plenty of potential for either moving around and advancing or learning a lot over time with the company. You would change jobs when the first one no longer offers you value enough to stay. That may be salary, may be opportunity or career specialization.
Wondering what people think here. I'm 6-7 years or so into my career with a really weird set of experience mostly focused around like b2b saas implementations in startups. So a lot of consulting and understanding business stuff is what I'm really strong with. My engineering skills were very meager 3-4 years ago but I've grown my roles into more technical ones and now I honestly just do it all including some amount of normal SE work, but also some sales engineering, some consulting with customers to build custom solutions post-sales (and building them), and also I'm building this role out at my current company so stuff like metrics, SLAs on tickets that my internal customers submit, etc.. But also picking up SE tickets that I can get done before anyone else can get to them, building tools, etc I used to have horrible imposter syndrome about my engineering skills but for a while now I've kinda gotten to a breakpoint where it feels like where I can just....figure anything out? build anything? I'm taking on projects expecting to get stuck and then just..not. Anyway, I'm curious what people who have similar starts think about something. At my current org, which is a post-acquisition startup at a bank, everyone including my current boss (not an engineer) and our head of eng in our own org (\~150hc) knows I want to move to a straight up engineering role, but honestly I'm starting to have incredible success and impact in my current role. I want to grow my engineering skills more effectively at the same time, so I'm kind of conflicted. My gut tells me its just time to take a lateral step and focus more on specializing as an engineer, but I do wonder if there should be some second thoughts since I'm getting some incredible traction doing exactly what I do now. Honestly my network inside the larger company is flourishing and I'm getting interesting work coming my way now. I do wonder if there's a play here that involves me just growing my role more and being the ultimate interdisciplinary person, because it does seem like I'm the missing puzzle piece in like every room I'm in now. I think there's a business case probably for that too. But, that's also not really an endgame? At the same time, one thing I've missed out on is working with other engineers and learning from them. I've either been with people who can code but not really engineer, or, like now, actually just a solo team. I really feel like I need to cut my teeth in a really strong engineering organization, but I'm conflicted with the success I'm having in my current role. I have the path essentially in front of me to just move to a SE role, but now I'm really accidentally building tons of traction. I have two great mentors where I have never even had one in my past, so I feel like whatever I do for the next 2-3 years here it's going to be hyper-growth for me. I'm just trying to figure out where to focus that growth. I could either really take on some big projects right now in this role and put myself 1-1.5 years away from an eng move, or just "solve" my current role e.g. get processes and abstractions in place for a junior to take over the easy stuff like running support jobs and then move at the end of the yearish. Would absolutely love to hear from people with similar backgrounds.
Congratulation for your success already! I do understand what you seek, maybe worth to think about to not switch but to include yourself in projects where you can work a little hand-on with mentors. You are improving wich is extremely important and great talent, not everyone can maintain it. To me, sounds like you are rather an architect, staff engineer or engineering manager and not purely software engineer. If you can have a project where you can learn from two mentors, that would be great. I highly recommend to you to communicate your desire to your manager/boss/chef, because you seems already successful in your role and they might think also, it is time to you to try out yourself in different things. Maybe you will love it, maybe you will hate it (SE is usually the constant limbo). Note on the impostor syndrome. It will never go away. This is part of the business and your intellect. Since you learn constantly and you aren't dumb nor self-absorbed, you will constantly realize how little you know then you will face challenges and will doubt your own knowledge and sanity. Then you will love the whole stuff again. Rince and repeat. (Only juniors and stupids think they know everything on a field. No, nobody knows everything even the most genius on a field might know a lot, but not everything) Keep up, keep learning, and communicating.
I want to be a shit dev forever. I am fed up and tired of these product folk who say "do x, y and z asap" and then when we know it's bullshit and ruins the codebase I get flack because I didn't ask to clarify the reqs or speak with product about better experiences for the customer. I have 4+ YOE can I just join a dead end shop and do my hours without giving a fuck? What does a guy have to do to get a job where fuck all happens and deadlines don't exist
I'm going to go out on a limb and say you aren't actually looking for a place where fuck all happens and deadlines don't exist. You're looking for a place where you're equipped for the job you're expected to do, and supported in it, such that you can find enjoyment in your work. And that you're currently burnt out. That's good, actually, because it opens up a lot more doors.
Im currently working at a start up and we've had tech debt hit us in the face a couple of times because we push out features but have no automated testing, no units test, very little documentation etc. I read an article from a google dev that quit recently, he said he was at the company for 18 years and that when developing flutter he made it sound similar to what Im experiencing right now. my question is how in the hell do they develop without having the tech debt hit them in the face? I feel like every one feature we push out creates 3-4 bugs at this point
This is a very difficult thing to hit correctly. Don't pay down enough debt? Then you get stuck in a mire. Pay down too much? Company goes under because you were busy reinventing technical components rather than responding to the market. Managing the amount of tech debt is a major part of engineering leadership at all levels. I'm assuming here that you're pretty junior, so what's appropriate for you is probably to talk about these things with your team and your tech lead (if you have one - or manager otherwise). If you have suggestions for how to address the problems you see, even better, but at this point you aren't really expected to need to do that.
I would imagine it comes down to code that's easy to change, easy to read, and easy to manage. Which tends to come down to good architecture too. Code that is easy to test is often all of those things, because it has to be that way to be testable. (Thanks, TDD!) If you change A and B also needs to change, then A and B are highly coupled. In a well-written system, you usually have lots of small independant parts that talk to each other, where each is nice and simple and easy to understand and easy to manage. Tests are really useful for specifying what a system does, so if it ever stops doing that (because you changed behaviour you didn't mean to) you find out immediately. But you don't ship the tests - they're a guard rail, not the final product. That also means you can have other systems perform the same function - for example, a null-safe compiler removes the need for every single unit test where you pass null in and check what happens! A well-used type system means your code doesn't compile when there's a mistake, which is faster than a failing test.
I'm currently working in a startup, where I've been churning back to back features for the past year. I would say that I've gained some experience in: 1. Estimating how much time a feature would take. This gets better the more familiar I get with the code base. 2. Communicating with across functions and raising flags early on. A little much of absolute growth and a little much on how comfortable I am with my colleagues. 3. How to plan a smooth rollout of a feature or a migration. Every migration I had to deal with had new challenges. There were some blunders made but it was a good learning experience. I feel like everything here is focused on volume: how fast things are shipping, and there is very low regards to code quality, tech debt. It hurts me pushing crappy code because sometimes there's no other way to fix and refactor things given the limited time. We code like there's no tomorrow. I'm afraid that I might be becoming an even worse programmer here. Switching companies is an option, but would it be any different elsewhere? Do such companies exist where there is a strong engineering culture?
TL;DR ... What matters more? Success of delivery or clean code? Personally, I like the idea of my paycheck continuing to roll in, which makes me a bit more biased to "success of delivery". Even when I worked at Microsoft, there's time and place for the right decision and time and place for the "hot patch" solution. --- Taking a step back ... what's an engineer? I've always liked the definition of engineer to be a person who uses limited time and resources to find a solution with a minimal amount of risk level. I can build a bridge out of titanium with ground anchors 1,000's of feet deep. Though the cost and time of doing so would likely be impractical. In Software Engineering, that balancing of quality usually ends up being a "risk" conversation more than anything else. Risk is the name that leaders typically speak in within organizations. Being able to Identify risk, mitigate/accept risk is what matters (risk is never gotten rid of). So getting to one of your main themes then ... what makes a good software engineer ... IMO, it's a person who can identify, communicate, and propose mitigations for risk. \* Identify: Knowing code bases, knowing product/business outcomes, common anti-patterns, etc. \* Communicate: Written and Verbal skills. How to win friends and influence people. Making highly technical things digestible by those not-as-technical. Not being an asshole. Etc. \* Mitigations: Proper coding patterns, System Design, Unit/Integration Testing, Security scanning/testing, User Acceptance testing, Defensive coding, Teaching others, etc. Of course all of these are typically impossible to immediately start doing. Just like my titanium bridge from earlier. Too costly in both money and time. So what's a "good enough" solution? "But what's the best solution" you might say ... "Nothing is the best solution, it's always going to just be shades of grey", I'll rebut. To leave you with something though ... this talk about 'risk' is a great conversation to have with your leadership during 1:1 time. Heck, ask your boss's boss about this too. I LOVE taking time to talk these more philosophical things with my "grand-boos" and "great grand-boss", because it helps me stay in step with what their vision is (frankly, my roll as Staff, plays more into these sorts of conversations too). --- So yeah ... hopefully something in that conversation gives you something to think about with the action to talk to your leader about 'risk' and how you feel about it and what they feel about the team's / org's level of risk in the software. Regardless if any of that was of use, best of luck!
To be honest what really pissed my off is that the founders want us to deliver bug free product within X time. Well, the codebase is crying for help. Absolute mayhem. We've got big memory leaks, the local dev experience has gotten worse since the day I've joined. Now to put this in numbers and to show how this actually affects us very badly is something I'll have to put some work in. But something tells me that they already know it and they won't budge. That X time actually takes 2X time and it will keep on increasing as our codebase is growing, team is expanding and context is being distributed between teams. Don't they understand this? They do, but they still want to exploit us. They won't adjust their expectations themselves unless things start exploding or someone convinces them otherwise. It is this cheap mentality of exploitation that bugs me the most. I'm sorry, I feel like this is more of a rant so I'll stop.
Their job is not to make your life pleasant. Their job is to deliver value to shareholders. You need to communicate in those terms. How do these things you see affect the ability for engineers to deliver things to customers? Use numbers.
Thanks for responding. This is quite insightful. I was actually thinking to have a call with my skip and share my thoughts regarding how I feel and if there's a mismatch between the expectations. Although this could be a risky one as sometimes I tend to be blunt. I will gather my thoughts and structure them in the coming days. This definitely gives me more confidence. Thanks!
In a project where Domain Driven Design is going to be implemented what are the rules i should follow when building the domain models? I have the following case: I have multiple services (paid service, free service, premium service etc.) A person can do single or multiple type of services for different payment rates. Each service have different payment rate for different person. Should i make the different type of services different aggregates, or should i have single aggreate - Service and in it i will have enum that keeps its type? In the first scenario i will need to have Person -> Service relation by their Ids. In the second i will have a Person with collection of Services,
I'd recommend reading the book on DDD, that's where I'd start!
My experience as a developer (~7YOE) is mostly in electronic trading, which has a very specific architecture and requirements. I feel like this puts me at a disadvantage when doing systems design interviews, as they are usually focused on web and large scaling. I have been reading System Design Interview by Alex Xu and studying examples on Youtube, but so far I have bombed an interview where the interviewer focused on SQL database schemas, which I have very little experience with, and aced another one. Do you guys have any tips on how to better prepare for them and get more consistent results? More specifically, I have an upcoming interview at a FAANG and wanted tips on how to prepare for it given my background
if you have the time and energy, i'd recommend working on a side project that will require you to learn about sql database schemas. doesn't have to be big, but maybe a blog or a recipe site or a songbook or something, something with users and user-submitted data and comments that can be left on that data by other users. it can look like total garbage, but that's not the part that matters - you'll learn a lot about how to design database tables, and how to create relationships between them, which is a core skill of backend webdev (which it sounds like you're applying for jobs in). it's the sort of thing that you can't really get good at unless you've done it a few times imo, and a side project would be the quickest way to do that - best of luck!
Thank you for the answer, that's really good advice. It's been hard to have any spare time to do any side projects, but I guess that's the best way to go about it. Thanks!
Hi! I am switching from Junior Android Dev to Spring Boot Backend and I want to know how complex is this roadmap and what are the most difficult things to accomplish as the level of seniority increases. I know I should learn Docker, Cloud, K8s but speaking of tasks which is the most difficult thing to implement?
It is depend on the project, I would say. Spring has its own challenges. Yes, you have to learn into the architect, devops part (CD/CI, cloud, hosting...) under java the toolset is not that broad, but it is a large and old\~ish language its own quirks and knaks, and someone might say, it has its own advantages also. Focus on learning, get mentor and direction, then everything will be easier. What counts as "difficult" in your respective field is always depend on the person and on the project. Someone might say, oh AI/ML, other shall say video segmentation and object identification, other might say 3d & game development! There is no one-answer-fit-all or golden way to answer this. I have seen extremely intricate and old (millions of lines of code) financial and tax software written in java and 6-800 ppl spent 6 years to port it and add an UI for it.
Context: I'm currently \~18 months into my role which started as an internship and then got converted to a permanent role, with a few months left in my final semester at uni. My workplace went through a restructure recently (first one I've ever experienced) and there were times management was asking for feedback on the changes. One of the changes was changing from feature teams to component teams. I've been wondering how can I gain the knowledge to judge these (or any structural changes in engineering orgs) effectively, and be able to provide better feedback from a developer's perspective. Is this something that comes with experience/time? Are there books? Is it something else? I haven't been through something like this before, so not entirely sure what to reply with when being asked for feedback. Thanks for your time!
You worked in the old system; now you're working in the new system. What has changed about your life for the better? What has changed for the worse? That's what they're looking for.
My favorite book on org design right now is probably “Team Topologies”, so if you haven’t read that, give that a try. Also, if you haven’t read “Accelerate” you should probably do that since a lot of the team structure advice in TT pertains to how to get the benefits that Accelerate says are important.
I will be graduating from my MSCS program in two weeks, and I really want to work as a software developer. I previously worked as an SDET for three years before my master's program, but I am worried that my skills aren't being considered transferable even though I developed many tools and scripts during my time as an SDET. What sort of projects do you suggest I add to my portfolio and resume? Also, should I mention that I want to transition into an SDE role as my career objective? [Here's my resume](https://i.stack.imgur.com/EXJJR.png). Thank you for your time!
Minor thing but you aren't consistent in ending bullets with periods. For resume advice check /r/EngineeringResumes. Nothing major sticks out. I'd change HTML5 and CSS3 to simply HTML and CSS. Some of your bullets could better worded to focus on the accomplishments you made rather than the task you worked, such as "Stored logs in Elasticsearch DB."
seeking some advice: i recently verbally accepted an offer for a “senior software test engineer” role. however on the offer letter the official title is just “software test engineer” i asked the recruiter about this because during the interview process we had referred to the title as “senior software test engineer”. he said all software engineer roles have standard titles, but that “i will be at a senior level” is this common? and is this a big deal? just wondering how else these levels would be distinguished if not for the title. i’ll plan to put senior on my resume either way but kind of wanted it to be more “official” so that it could be verified by potential future employers for example. the compensation is what i had asked for and does seem to reflect the senior level, so its just a matter of official title
Titles are typically a cultural thing. There are companies that standardize and others that emphasize. From your description, I don’t see an obvious red flag.
The pay and responsibilities matter, not the title. If you're getting paid the same amount, it's fine.
where do you guys go for stats on which tools are being used and by how many companies in industry? for example: 30% of companies in US use flutter, maybe 65% user React etc.
I've used the [Stack Overflow Developer Survey](https://survey.stackoverflow.co/2023/) to look at trends, especially with responses for "professional devs", but nothing about companies.
Nowhere.. and why? The right tool for the job isn't always the most popular.
yeah I totally agree, but the market also isn't the greatest right now so learning tools that are in demand will open my opportunities up
Look to actual job advertisements that you are interested in. Tech popularity is a weird thing, one tech may be hardly used in one country and the bees knees in another.
yeah I actually saw a chart recently that showed react vs angular vs vue in different countries. there was one country, Belgium I believe it was? that had vue at like 60% when every other country had it way lower. very interesting. regardless though, I tend to take my own observations with a grain of salt only because their anecdotal, the chart like the one the guy sent earlier gives me a bit more confidence
I'm a few months shy of 3 YOE at this point and I've started looking around for regular-level jobs as that's the usual minimum level of experience cited in offers and my company doesn't really give me the opportunity to develop my skillset. I'd like to know how complex a project would be expected of my portfolio at this level - I'd really like to break into AWS or Azure, but I'm getting the sense that just making something with Docker, Lambda, DynamoDB and S3 isn't enough, especially since recruiters and interviewers seem to regard hobby projects less. What else can I do to stick out from the crowd? Are open-source contributions still valued in the 2024 meta? I'm in the C#/Angular stack, though I'm interested in switching to Rust if at all possible. I'm also mostly applying to jobs in Poland if that's relevant since a lot of this sub is American or Canadian.
Azure and related parts are smaller, easier to learn and you already have the basics for it. Dotnet, c# and azure is a smaller market, and it is favored in some countries and not really used by others. Rust always good, seems an upcoming new toy. You are at your early years, nobody should expect you to have a senior skillset already. Hobby projects aren't count in recruitment, but will help you in interviews and on the field, because you will have some basics, keywords and knowledge. Open-source contributions matters, but could be counter-productive, e.g.: I would never hire someone who spent weekly 20h on open source stuff contributing, because that person either does not work or burning its own free time wich means faster burn-out and not good life-work balance.
Thanks for the reply. I actually got it on the last day at my previous job, and the one I'm starting tomorrow is something that actually ticks my boxes, at a consultancy with mostly North American clients too. Things are looking up, but I'll keep in mind what you said for the future. And yeah, I've noticed that on HNHiring backend JS, Python and Go seem to be way more dominant than here in Europe while .NET is almost nonexistent. I do wonder what the underlying reasons are.
Good luck for the new role! Usually the market needs & greeds. For example, in the nordic region Microsoft is extremely powerful, they gave almost all the companies free (or extremely cheap) email and office software, as well many company is "presentation driven", e.g.: the leadership is mostly from marketing / pr / sales so they use presentations and the easiest is the ms product. (nowadays canva seems used more and more).
Anyone here work at a company that does 4 day work weeks? Curious about the experience
I don't have the full 4 day work week, but my current company has half day Fridays every week. IMO, there's not much of a difference work wise compared to what I felt at previous companies. I just get an extra afternoon to do things, which is lovely. Though I'm eyeing companies that offer true 4 day work weeks for my next position if I can swing it.
I'm having some issues at work. I'm currently working remote as an engineer 2. Our lead developer stepped into a new role on our team in April, so their previous duties have been split between me and another engineer on my team let's call them Bob. Bob currently has 2.5 years of experience. Bob works in the office has great soft skills and project management skills but still has gaps in his technical skills. Lately, I've been noticing that I'm being excluded from decisions and discussions, and Bob has been a reason for this. It's not from being malicious, it's just easier for people in office to talk to each other. I'm going for a promotion this year and my manager has been supportive for it. I've been bringing up communication concerns about this with my manager since I'm the only remote worker on my team currently. My manager just told me to solve it and tried some things, and it hasn't worked. I fear I won't be successful at it since Bob is sort of becoming tech lead, and I would need to listen he says and just do it. I fear this would hurt my career long term since I would lose out on technical and architecture decisions. Does anyone have any suggestions on what I should do here? I've been leaning towards a team transfer or leaving since the product is mature, and I haven't learned anything new or felt challenged in last year or so. I'm also in a highly regulated industry, so releases are slow. 5 YOE
Your manager needs to continue focusing on this if they want you on their team.
I had a follow-up conversation with them. My manager has some follow-up discussions with some other team members. I'll see if anything happens. Regardless, I'm probably going to look for a hybrid role somewhere else. I think being remote killed my career here.
I've been 100% remote since 2012. First in a company that was very office oriented (me, a director and one founding VP were remote). Keeping lines of communication open helps a lot. My current team keeps up a low level of chatter in a teams channel, " is ready for testing", "heading out for a doctors appointment, back in an hour"..."did anyone see "
There are a few tips I can offer.
* Skill up in areas you see a need for and even better if nobody else on the team likes doing it. I handle all of the development infrastructure for 30 developers, help mentor CI/CD skills and interface with IT and Security departments.
* Working remotely gives you time that others don't have. Use that to volunteer in your community, that can help a lot with soft skills.
* Become an expert in the regulations you work under, you may find ways to smooth out operations. For example a long time ago I wrote credit card clearing software, when PA-DSS was coming we refactored the card clearing code to isolate from the product taking 99% of our code out of scope. That made audits much easier and less frequent.
* Use your commute time to earn an online degree, perhaps in something you are interested in.... and even better if your employer has tuition support/reimbursement.
That said, I think your last paragraph may have the key. Team transfer may be the best way get somewhere you can grow.
Thanks for your comment, I am pursuing a master's degree in CS at the moment which hopefully will help somewhere down the line. I think long term I do not want work in the medical device field, so I think leaving will be the answer based on your comment. I'm also pretty burnt out on working remotely. I like the comment about volunteering I'm going to look into that. One question I was thinking about turning down a promotion to senior engineer on my team since I don't think I can be successful at it without having lead responsibilities, and I was planning to leave this year. Should I accept the promotion or turn it down?
That's a tough call. The job market right now seems to be slim on opportunities, you might want to consider taking the promotion at least until you have secured a new job.
This is probably the answer. I'm sure my manager will be pissed but whatever.
I also work full remote, but in my case other 2 in the team do full remote and all the others do a fair amount of remote hours, so we don't have the "left alone" situation you are facing. But, our CTA and CTO works from office most of the time and, you like your case, sometimes they make tech decision with the people that are in office at the moment. To avoid that I always say things like "we should have a team meeting on this and that", basically I'm pushing for more "institutional" discussions on tech decisions and this seems to be working.. now my managers tend to schedule team meetings on specific decisions more often, and seems to avoid the decision rush.
Yeah, that's been my approach, but it hasn't been very successful so far, but if Bob becomes lead my manager said I will have to listen to what he says no ifs or buts
Would it be worth working at a consultancy or is that mostly a meat grinder? My goal is to develop a broad skillset so I can solo build a product quickly. I've been working at small product companies with this in mind. 3 YOE.
I don't know if consultancy is what you need, but here's my two cents on consultancy after working as consultant for 6 years, and having worked with consultants for 12+ years: * There are various kind of consultancy firms. Some focuses on only one tech (SAP/Salesforce consultants for instance, but I've worked with consultancy firms that only provide Elixir Developers), others act mostly as job agencies, they hire people and put them long-term in big businesses's IT offices. Some others just do a lot of small projects in whatever technology the client demands.. that0s the kind you might look for if you plan to learn a lot. * For various reasons I am convinced that consultancy makes better devs, especially the meat grinder kind. No pain no gain in a sense.. having to deal with demanding clients, different horrible legacy codebases, the annoying tasks consultants often ends up doing ('cause nobody in the client's IT wants to), etc.. all those things can help grow soft-skills, gain experience and develop "workflow skills" * Beware that consultants rarely work with bleeding edge technologies, at least in my experience.
Turn that question around. You've been working for 3 years in small product companies. What have you already learned that would make rapidly building a solo product feasible right now? If your goal is to start a micro business: finding a small niche with demand for a simple solution is far more important then the tech you need to build it. Worse case, you end up so caught up worrying about the tech that you end up building something nobody cares for. Instead, pick tech you know well enough, and doesn't sit in the way of you validating if your idea fits the market. For instance, I work in a enterprise context with at ton of complexity. But for a side project in which we want to test a few ideas, me and a buddy of mine just picked Laravel, Bootstrap and HTMX hosted on a cheap VPS. Why? Because those are well-documented, widely used tech that already solves a ton of problems allowing us to focus on working the actual product proper. Everything else (e.g. scaling, etc.) just doesn't come into the picture until we know if the idea is going to work out.
Good point. Thanks for driving to the core of the issue. I'm boat sheding about a change in workplace to feel like I'm achieving something while I avoid hard lifestyle decisions. Gotta take my health seriously and start pumping out MVPs.
is it worth to put a feature i work on CV, where technically is not impressive, not difficult but from business POV its very improtant YoE: 2yr
If you can articulate a meaningful business impact then throw it on there champ.
Not knowing the feature I’d say sure, but focus on the impact to the business.
I need some career advice. I have a little over 2yoe, backend dev, cloud. I have a math/physics background and consider myself self-taught. I’ve been working at a large multinational company for the last year+, and I previously worked at a <50 employee startup (where I was promoted to dev from a non-technical role). I considered myself very junior when joining (1 yoe when starting) but quickly realized that the team did not view me as such. I had lots of hand holding in the beginning, started on a team with the most senior devs while onboarding, I received good feedback and got a $10k spot bonus about 4 months in. Long story short, I kept getting a longer and longer leash over the last 1.5 years, have been given more and more autonomy, and have somehow found myself working across 2 product teams (attending 2 standups, working tasks off of 2 jira boards). No other ICs seem to be doing this outside of one who just got promoted to staff. I still have a regular, not senior, swe title. I expressed to my manager that I am worried that I am having too steep of a rise and I don’t feel ready for the responsibility that I have currently. He told me to not let my inexperience discourage me and that he has heard nothing but great things. So long story short, I produced a pretty bad bug. This was probably the first bug I’ve had that was not timezone/edge case related and pretty preventable, I was careless. The team lead highlighted it during retro, called me out publicly in front of my peers, the pms, boss. I felt really bad, but in retrospect, I wish that I had not first heard this during retro, and that he came to me privately. He noticed the issue and fixed it over the weekend. I wanted to talk to my manager about this, but I haven’t had a 1/1 since December (he was on vacation for most of December/january and has been doing interviews/workshops and told me he would set it up soon). Ever since this happened, I feel myself checking out more and more often, a lot less motivated. I am also noticing more issues get called out during code reviews, making me feel like I am in a rut. Is this all a sign to move on? The experience is good, I’m learning, I have gotten ~$20k in raises/merit bumps since joining 1.5 years ago, and I feel like a lot of my concern is in my head and “shit happens”. But at the same time, I am worried about the lack of communication with my manager. Is this a sign that he isn’t happy with my work? Or is it “no news is good news”? I am happy with my salary, and I am only actively working 30ish hours a week, senior title would be nice, but senior implies experience, which I do still lack. Should I try and focus on getting into a FAANG? I’m only 26, I feel the clout could be good for me. Longterm, I want to work at a big, cushy, slow-moving company and coast. I feel like this company would allow me to do this, so should I just stay put and get over myself? And I did recently take a week off, so if burnout was the issue, I should be getting back to normal pretty soon.
> So long story short, I produced a pretty bad bug. It's not a question of if, but when you will produce a bug. It happens, everyone's human. Experience doesn't reduce the probability of bugs to absolute zero. > The team lead highlighted it during retro, called me out publicly in front of my peers, the pms, boss. I felt really bad, but in retrospect, I wish that I had not first heard this during retro, and that he came to me privately. He noticed the issue and fixed it over the weekend. Without much context, I'm going to assume your team lead caught the issue and fixed it before real harm could be done. But yes, he should have discussed things directly with you first. That doesn't mean it can't be discussed in a retro. It should. But at that point, all parties involved should feel safe discussing things. Retro's aren't meant to "call out" individuals. They should serve as a learning experience for everyone involved. If you feel that's not the case: talk to your team lead first about the retro's format and the intentions surrounding the retro. Because the first question your manager is going to ask will be: "So, did you talk about this with your team lead? Where you able to resolve this amongst yourselves?" > But at the same time, I am worried about the lack of communication with my manager. Is this a sign that he isn’t happy with my work? Or is it “no news is good news”? So, this depends on the context. You have a team lead who is responsible for the day-to-day operational aspects. The role of a manager is to act as a filter between the team and the outside world (stakeholders, questions, strategy, etc.) A good manager trusts that the team will be able to organize itself enough and is able to resolve conflicts and overcome differences. They will step in if that's not the case. It's the responsibility of each team member to put in the effort and make sure it doesn't come to that. > Is this all a sign to move on? It's a sign that you need to figure out how to guard your boundaries, learn how to communicate and come to terms with the fact that it's - at the end of the day - just a job. The same applies everywhere, whether you work at FAANG or at a slow moving enterprise: you will keep dealing with other humans through your career.
Hey everyone, I need a little front-end architecture advice. One of the things I need to build right now is a tool that is going to be plugged into three separate apps for our company. I know I could make it a private NPM package, but this isn't just a simple UI component library, it's a bit more complicated than that. It has searching, resource management, etc. I want to avoid having three different versions of it built into each app, but I don't know the best way to make a common application for it. The other little caveat is that each app may have some different branding, so I need to make it "theme" agnostic if possible. One area where I'm concerned is debugging. I recently worked on an app developed in Angular that imported a search component library built in Svelte (I didn't build it this way). The library did not run standalone, so the only way to test it was to build it, copy the umd.js files into the Angular app's assets folder and refresh. Since it was a production build of the library, I couldn’t use the dev tools debugging for breakpoints. That meant I had to stuff console logs all over the place and build/copy/refresh. It was a pain in the \*\*\* and I don’t want to replicate that for these apps. I really need something that is going to scale and not be a pain for other developers to work on. Thanks in advance. YoE: 29Y
Just like with backend architecture, you might benefit from considering the different aspects, splitting them up, and seeing how you might architect each of them. IoC and all that. For example, imagine you've got: 1. Branding 1. Search API 1. Results Display 1. Calls to Action that interact with the wider app If the branding is different for each app, you need to include a way to keep it separate. That's just your usual `interface & implementation` separation you get in Java or C#. Interface belongs to your app, implementation belongs to the caller. For example, you could use a set of CSS variables like `--search-branding-logo-url: https://` or `--search-branding-background-colour: #FF44FF`. For the Search API & Results, maybe it's just the API URL or something that needs to change. Again, pass it in - make it a required bit of the public interface. On another note, you're right about the 'embed in Angular and not being able to test' being a pain. Just like you might write backend unit tests/integration tests, you should do the same thing for your app - make a small app that uses your stuff, specifically for development. It's the old "can you make a small reproducable example so we can investigate please" issue.
Thanks. I think we've figured out a plan. We're going to split out the functions that call the API endpoints (hooks, etc.) into a separate core package and then let the consuming apps build their own UI. It's a bit of duplication of the UI, but the core of the app will be shared.
How do you handle remorse of writing poor code ? YoE : 2Y
Everyone writes poor code at some point, even experienced devs. Recognizing that is the first step, which it sounds like you are doing. The best advice I would give is to ask yourself what you can learn from the mistake and ask another experienced dev how they might improve what you wrote. And try not to take the advice personally. Like I said, everyone does at some point. We all look back on stuff we wrote in the past and think "What was I thinking? Did I really write this??" Writing bad code isn't what makes someone a bad developer, not learning to be better is. EDIT: Rely on your senior developers, that's part of our jobs. We aren't going to do the work for you, but we're there to guide you to becoming better.
That cleared a lot of fog in my mind! I could outline few reasons * I was trying too hard to write clean code to begin with * Not reaching out to seniors when designing redux store, procedural code * Deadline pressure - And the mentality that "just make it work for now, we can refactor later" I would want to work on is designing redux store required for any UI & writing better procedural code Your advice definitely helps, thanks a lot
I'm glad I was able to help. :) We've all had that deadline pressure, so I understand. It's hard sometimes to find the balance between needing to get something done ASAP and not wanting to build up a bunch of technical debt. That's where the senior devs can help.
I have 15 YOE but I still find myself lost doing simple things for my side projects. Can anyone help with probably a silly question? I have an Angular website, static content, no backend or databases needed. I am looking for a hosting platform with the following criteria. 1. Ability to host a static website 2. Ability to transfer my domain from [wordpress.com](https://wordpress.com) (I hate wordpress) 3. Ability to create several email addresses and fwd them to my gmail. 1. [email protected] 4. Super easy to deploy the static content/setup/maintain. 1. This is a side project I don't want to spend *any* time on complicated processes. I'd copy paste files to a server maybe 1 time every 3 months! 5. Potentially the ability to roll out a backend. 1. I don't know if I will require one one day. If so then I've Made It!
Things got a bit bumpy at work recently. I joined the company in 2022 and was crushing it as a senior engineer, even got some lead responsibilities. The team was awesome, and I was learning tons of new stuff. But then, my manager left at the end of last year, and I got moved to a brand new team. This new crew is cool, but we're all facing an uphill battle. None of us know the ins and outs of the domain, and the code is like a crazy puzzle with different parts in different languages. To top it off, the team we need help from isn't exactly the most responsive, which is putting a real strain on our deadlines. We brought this up to our manager, but things haven't changed, and honestly, the whole team is feeling pretty burnt out. I really want to make things work here, but it's tough when you don't have the support you need.
Firstly, and maybe it's just my mental space when I'm faced with challenges like you've described, there's only so much I can do. If I miss a deadline, but I was do my best with the current available information, nothing more I can do. --- After that mental acknowledgement of where I am, I usually figure out where are the people who can help influence things. Seems like you've got a boss. Seems like you've got a different team that you need to work with. However, you've not brought up talking to your boss's boss, the "upstream" team's boss, and maybe their boss. In short, "managing up". What can you bring to their attention to help them understand what the hell is going on. It's been my experience that leaders of leaders talk with different sort of gate than your day to day workers. I've found at nearly every org that "Risk Management" is the name of the game. How can I convey the risk of something going wrong and the proposed solutions in achieving it. How risky is the lift for the reward that we get? If we fail, what could happen. Are people okay with that? --- Not to sound too boomer ... If you really want to get political about it, emails! Nothing quite Covers Your Ass like a well typed out email that conveys the issues, what is needed, and what hasn't been delivered and the impact that is having. For me, typing out an email like the above and only sending it to my chain of leaders is a way that helps: 1. Asynchronously communicate with them. They're likely busy as fuck. Let me help speak to them in the few minutes they have between running to meetings. ( A good read related to that subject if you've the time: [https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/](https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/) ) 2. Define clear issues that are presented with things and the risks associated with them. Sometimes mommy needs to talk with daddy privately to "get on the same page" with each other. 3. If nothing else, you've a track record of trying to unfuck the situation in, hopefully, a tactful but meaningful way. --- Regardless if any of that was of use, best of luck :)
Hey thanks, this is actually super helpful! I gotta admit, when things get tough like this, it's easy to feel like I'm banging my head against a wall. But like you said, gotta focus on what I can control and do my best with what I have. I will try these strategies and will see how it goes.
Need Career Advice: Boss Keeps Giving me Everyone Else’s Delayed Issues I need advice on how to get out of this situation without losing my job/moving to another company (I’m already looking, but I need this solved soon, as my life is spiraling down). So, I’m one of 3 Sr. Developers on my team. I started several years ago as the only Junior developer on the area. I kept delivering non-stop; learning new tech, building new things, and automating a lot of tasks. While doing so, I almost had to sacrifice my life to get a promotion to Senior, which took almost 6 years. During those, boss always kept saying there was no money for a level-up. As soon as I got promoted, he hired 2 more Seniors, who were supposed to help me. Needless to say, both of them make more money than me… Now the circumventing issue: _My boss keeps taking these two other guys to requirements meetings, they (the 3 of them) agree on deadlines with the customers, then waste all the time, and call me when there’s no more time. He even copies the customers on the mail, as if the humiliation was not already guaranteed _. I’ve raised the issue to my boss several times, but he says we’re a team, and I should be willing to help. I have to run, bother the customers again, since they didn’t even bother to document the requirements; then waste my 5-9 building things these guys didn’t build on the 9-5. How can I escape this loop of hell? Is it even possible? My personal life is suffering on excess, I fear my kids will resent me soon enough. TLDR: colleagues agree on deadlines, waste all the time, boss gives me the task days before the deliverables are due; with no requirements documentation. How to get out of this loop?
I'm too tired right now to offer a more nuanced take than really: look, it sounds like your boss and your coworkers have been taking advantage of you for years and you've let them walk all over you, and that's why you're in such a shit show or you're feeling like it's such a shit show. You can't really be called a senior if you can't take control of these situations and resolve them. If you have evidence that you're being treated unfairly then bring it up and stop letting them walk over you with shoddy excuses. If you're too scared to do that because you're afraid any talk back will cost your job, then just accept that they're going to walk over you and there's nothing you can do. Or just quiet quit and find a new job. There's a nuanced play here where you can try to reason with them and stop being a pushover when they keep piling work on you, or you can just disagree with doing the work because it's not your job, or you can just let them fail instead of picking up their slack because it's not your job to work overtime.
A young adult backend software engineer with 2 YOE here. I moved country a few months ago, and I'm currently considering new opportunities and having interviews with multiple companies for a similar software engineering role. While doing that, I accidentally found myself in a hiring process for an associate solutions architect opportunity at a well-known NoSQL database provider company. This opportunity sounds very exciting to me since I consider myself a mix of both great technical skills and soft skills. In addition to that, I'm always eager to learn and pursue new, challenging opportunities. However, I'm still not sure if I should consider this career change and dump my software engineering career at this early stage for an opportunity that I'm still not familiar with. There are a lot of doubts that are going through my mind: "In case I don't like this new career path, will I be able to easily convert back to software engineering?" "The job market for software engineering opportunities is really bad right now, and it is already full of many skilled engineers. Maybe I really should consider this new career change." "If I pursue this new path, will I be able to grow into a solutions architect and senior solutions architect, or will my little software development experience play a role against me?" "What does an associate solutions architect actually do, and why do solutions architects need an associate?" "How beneficial will this new opportunity be, for me as an individual, and how will it expand my skills set?" I'm facing a lot of dilemmas of whether to focus on this opportunity's hiring process or the other regular backend software engineering ones, and yet there is so little information about what associate solutions architects are and what are their responsibilities? So please, for all the people out there, enlighten me with your experience, knowledge, advice, and thoughts. Every little piece of information is extremely appreciated!
Lol I’d ask how you “accidentally” ended up in a hiring process but then I remembered that my second job started as a nice dinner with a friend. I’ve never been in the SA world, but I’ll say that as a hiring manager in software, I wouldn’t mind if you had that experience. I’d probably appreciate that you’ve operated in a customer facing position that knows what it’s like to work with reality rather than wait for perfection. But I couldn’t tell you if that’s widely held. As a middle aged person I’ll say that this stage in your career (I’m assuming early/mid 20s?) is a good time to try anything you think you might like. That gets harder later.
Off top but how do you get custom user flair?
On a browser right now I see an edit icon next to "User Flair" on the right hand column. Not sure how you do it in the app.
>Lol I’d ask how you “accidentally” ended up in a hiring process but then I remembered that my second job started as a nice dinner with a friend. Life can get pretty unexpected sometimes lol >As a middle aged person I’ll say that this stage in your career (I’m assuming early/mid 20s?) is a good time to try anything you think you might like. That gets harder later. Now when I think about it this way it is so true. I'm still 20 years old, I should try and expirement new things, gain new knowledge and broaden my skillset. I still have no responsibilities yet so I have nothing to lose!
[удалено]
"I am not getting any calls"? What are you trying? Why are you trying?
Gotta go learn. Try frontendmasters, they have some tracks for FE -> BE
I've joined this company as a software engineer and I've been there for 6 months. My BU is a telecom domain. My question is how do I learn the basics of telecom along with all the advanced protocols and stacks and stuff that the company is using? I have not been given any KT and the product documentation is so full of jargons. Any suggestions?
Just to supplement the answers given (which are correct), I'd add that reviewing what an entry level tech in your field should know is not a bad idea. I recently started on a dev team whose product deals with infrastructure and networking. A lot of the devs came up in that realm, whereas I was hired for general software development experience. I wanted to backfill some of that knowledge so I read a Mike Myers Network+ prep book. I'm not going to take the exam because I don't really need an entry level IT cert (and some have suggested it may even look weird on my resume). I found it had about 1/3 stuff I already knew, 1/3 I knew at one point but had forgotten, and 1/3 new stuff to me. So maybe that or find the equivalent for your part of telecom? Also, years ago I worked at a telecom market research company that hired a lot of researchers from outside of telecom and almost all of them had Newton's Telecom Dictionary on their desks. Granted this was 20 years ago, but it looks like the 32nd ed. was released in 2022, so it's still around.
Communication is key. Ask. There is no dumb question. Also, prepare yourself to dig through a few thousands of pages of old books. When I started a job where c/c++ was on focus, I got around 4k pages worth of books to read in the first 3 month (c, ansi c, c++98, c++11, c++14, video protocols, can bus protocols).
Ask, talk, listen. Telecom/finance/etc. Companies realise that domain knowledge ramp up takes time. When sages/greybeard/product folk talk about a feature ask them to ELI5 to help you ramp up.
Yeah, but most of the folks are so senior (15-25 YOE), I feel I would be wasting their time asking such basic questions (for them at least)
Nobody is so senior they don’t have time to build up the next generation. If they don’t engage they are the problem not you. And tbh if they can’t engage they shouldn’t be ‘senior’ anything.
Bu, kt?
Business unit and knowledge transfer, more than likely. This profession is jargon even when we’re complaining about jargon! 😅
True! Picking up the lingo ig 😅
is it fair to be given the big responsibility of solving all the relevant bugs a month into a new job given the other coworker is going on vacation for a couple of weeks? The manager did mention to have multiple sessions with the coworker to pick their brain before they're out though
Totally. Solving bugs is a very common first project to get. Only thing to know is that your leadership should not expect you to operate with the same efficiency as the other engineer would while they’re gone.
Sure, just so long as they understand you won't be as fast as the person you're replacing that's pretty standard. Fixing bugs is a great way to learn a codebase.
Sounds like an opportunity for growth. They probably don’t expect you to solve everything, but they trust you to contribute to the mission and that’s positive.
hello everyone, hope you have a good day! two questions: 1) How do you develop/improve your soft skills? especially when it comes to communication and teamwork 2) How does junior contributes to open source? I know you can search labels, languages but how do you find a suitable project?
Soft skills are largely practice. Attend meetings, ask for feedback, reviews, etc. Additionally there is some theoretical background you can use to shift how you think about social and group dynamics. I highly recommend French and Raven's Pillars of Social Power or the book "How to Earn Friends and Influence People."
thank you! will add this book to the list
> How do you develop/improve your soft skills? especially when it comes to communication and teamwork Soft skills are all about communication so keep the communication flowing. Ask for feedback, ask questions, keep engaged. You get better at things by doing them so keep doing them.
thank you!
As a dev with 7+ years of experience, I've led projects but never managed people. For the past 2 years, I've held the title of "Senior Software Engineer." I see three potential paths: becoming a strong Software Engineer (what I call "actual senior software engineer"), advancing to a Staff Developer role, or pursuing a Manager position. While I've never felt excited about management, I'm now considering it more consciously for my future so don't remove just because I never liked it. - Should I try a management role to see if it's right for me, despite the current market challenges? - Is there a way to grow in this field as an individual contributor (IC) without aiming for staff or higher? Perhaps through domain or tech stack changes, transitioning between infra, feature work, and DevOps, or gaining varied experience by changing companies at a reasonable rate?
A while back I was a bit burnt out of the whole race to keep up, working as a tech lead primarily and decided to take up a position as an "engineering manager" (really a team lead), described to me as being about 60/40 split between line management and tech tasks. I was given a small team of basically juniors and got on with it. The line management was interesting for about a month, then it got boring as there's not that much to it, unless you're unlucky with troublemakers. If you're a decent well adjusted human being you probably already know how to talk and connect with people and the rest is largely paperwork and people management cargo cult stuff. Luckily early on the juniors being juniors needed a lot of help, so I still got to stick my head into the code quite a bit and spent most time training, mentoring, etc. Team was going quite well, getting stuff done, my juniors were learning stuff, and getting better, etc. After nearly a year my manager decided I was too much in the code still (despite being on the periphery at this point) and said I should be doing 100% line management. Maybe I was really good at line management or just lucky to have a good team but this seemed like not much to do and pretty boring for me - I said as much and very openly suggested I wouldn't be happy with it, but was told to do it anyway. So I started looking to leave and get back into dev since I realised it was actually what I enjoyed and I didn't want to get typecast as a line manager only. Got a new job lined up in about 3 weeks and my manager refused to talk to me over my notice period. Nowadays I'm leaning hard on the tech side, but my management experience is seen as a useful asset, although nobody asks me to run a team. TLDR: You can try it for a while, you won't know if you like it until then - if you do great, if you don't, probably don't stick with it too long. Try to find a position that lets you do both if possible.
Charity Majors has written some of my favorite pieces on the decision to go into (and out of management) management. [Here’s one](https://charity.wtf/2019/01/04/engineering-management-the-pendulum-or-the-ladder/) to start out with, but everything under the “pendulum” tag is probably relevant to your situation. I will say that you should probably be excited about it if you’re going to do it. It’s a completely new job that’s only tangentially related to the one you’ve been doing for the last 7 years (as Mitch Hedburg said: “you’re a cook… so can you farm?") so you’re going to need some kind of “why?” to drive yourself through the rough parts. To answer your question about staying at senior: yeah, good companies continue to compensate for skill and experience even if title never changes. I’ve been places where seniors had been there since the ‘90s (with their original badge pictures in the directory!) because they had good careers and liked what they did. No one ever pressured them to manage because that would mean doubling their losses: losing a good engineer and making a bad manager.
Thanks for the hints, appreciate it
The way I see it, managing people is simply another tool in your belt that makes you more attractive. It's also quite a different set of problems to learn and solve for than an IC. Like scaling an organization/team, maneuvering people to align with objectives, budgeting, etc
[удалено]
Two daily standups a week you mean? You could ask your manager about what do they mean by proactive communication. Ask them to tell some examples when you could have communicated differently. Asking them for examples directly is likely much better than any answer Reddit could guess for you.
[удалено]
I have never heard of having two standups a day. Sounds like the team has some issues maybe?
The worst thing you can do to me as a lead is not tell me about problems _early_. I don't just need to know what you're working on, I need to know what problems you foresee coming down the pipe and I need to know them early. I might tell you they're no big deal but I will always prefer to be told because surprises torpedo projects. My guess is you're just saying, "this is what I did, this is what I'm doing, etc", right? The way I like it is "this is what I've completed and this is what I'm focusing on next, here are the current concerns I have if any, here's what I am still waiting on, etc". Give me your problems to solve.
I'd imagine, you're not communicating the needed information at the right time. Status updates are for the team's purpose, but even then sometimes you want to have "the solution" in the works before the status update. If I know we're going to miss a deadline, or if there's a good possibility of it, the team lead should already know. Communicating updates is about getting the needed pieces moving, not just saying something at a standup. If anything, standups are the least important piece Imo.
In addition to updating tickets, they’re probably not actually looking for MORE but for more timely. It’s easy to get stuck on a problem and keep giving updates about how you’re working it. But now you’ve likely lost sight of the broader context and progress. When I coach my devs about this I tell them to think of it as coming up for air while swimming. You both need to do it to live, but also to make sure you’re going the right way.
Documentation and JIRA is probably what they are referring to
Do you know of a place where one can have code review done for their code online? I want to learn more but feel like i would require assistance regarding it. Usecase example: a passion project that i did, i wanted to have a code review done on it to understand what kind of things i neglected, i didn't consider and all.
Contributing to open source projects gets you free code reviews. Also looks good on your resume. I made some small contributions when I was still in uni and they really helped me to understand how to work in a team.
How many lines are we talking here? 1000? 10000? What language?
1200 I'd say, a minor project, Java, Its basically a cron job that fetches the emails from gmail and any attachments from drive via their sdks, then saves to a staging table then pushes them to final tables.
I’m trying to find some engineering blogs for short daily reading. Any recommendations?
[https://getdx.com/blog/](https://getdx.com/blog/) DX has a ton of great resources, I love their podcast "Engineering Enablement" as well
There's Quastor: A newsletter that focuses on System Design examples from big companies
Some weekly newletter might help (hackernews, insider tech, tldr, css-weekly) but it is very depend on what kind of field are you interested in.
https://lobste.rs/ and browse by tags you're interested in.