if this is just a workload vs capacity thing -- where the workload exceeds capacity, is there a way to add some back-pressure to reduce the frequency of on-call issues that your team is faced with?
are you / your team empowered to push back & decline being responsible for certain services that haven't cleared some minimum bar of stability? e.g. "if you want to put it into prod right away, we wont block you deploying it, but you'll be carrying the pager for it"
Some people in industry wearing a "data scientist" hat may be working with R. I worked with a few people in a for-profit megacorp who had developed a particular forecasting model in R -- that model ended up getting rewritten in Python to "productionise" it, but a few of the folks who developed the original R stuff came along for the journey.
Maybe another approach to searching could be to try popular R libraries with unusual/rare names as search keywords. searching for quoted things like "Python or R" might also find you a few candidate jobs.
> What reasons have you found that make you want to stop being a Software Engineer?
this is an excellent question. each individual may give different reasons, and the reasons could suggest completely different occupations as a good fit. this requires a bit of self-reflection to unpack what exactly is motivating a change.
dislike being on call? struggle with delivery pressure? don't pick a new job with on-call responsibility or a "real time" delivery aspect.
dislike having low autonomy? don't pick a new job that also has low autonomy. pick something where you're the boss or have some well-defined responsibility.
dislike being stuck in a cube farm? don't pick another job where you wear a different hat but end up stuck in an equivalent cube farm.
dislike not being able to see real world results of your work in less than a year? don't pick another job in an sector with very slow feedback loops.
(i'm revealing a bit about my preferences with the above example questions, but hopefully the general idea comes through... )
> My advice: find the best paying SWE job you can find.
> At the same time minimize your expense.
Some people frame this as first accumulating savings, then quitting the job & depleting those savings to buy time while taking a holiday / switching to a new career. That's valid, but it glosses over that you can put your savings to work to generate income.
Another perspective is the FIRE (financial independence / retire early) angle, where you accumulate savings and invest them, then when you pass the point where your passive income from investment returns exceeds your living expenses, you achieve "escape velocity" and no longer need to perform income-generating work. indefinitely. You need to accumulate investments worth roughly 25x your annual expenses to hit this point (assuming a 4% return on investment, net of inflation).
One way to do this is to achieve an after-tax savings rate of 75% for about 8 years. Suppose after tax, for each $100 you earn, you consume at most $25 of it on annual living expenses, and invest the remaining $75 surplus in the stock market. If you can repeat this for 8 years, and you've been holding your annual living expenses to a sustainable level (not artificially low) then there's a very good chance you'll be financially independent and the "long period of rest" can be indefinite.
yup. i recall first being exposed to this while trying to understand why a memory-hog backend service was being oom-killed in production while attempting to spawn a resource-light subprocess via fork+exec, while there was still a good portion of free memory to use.
the more you read about linux oom killer, overcommit, linux memory accounting heuristics, copy-on-write, fork+exec as a mechanism to spawn an unrelated process, the more surprising it is that anything works at all even some of the time.
what decision / downstream process is going to consume the 1B node graph render? is producing a render really necessary for that decision, or is rendering the graph waste?
is there a way you can subsample or simplify or approximate the graph that'd be good enough?
in some domains, certain problems that are defined on graphs can be simplified by pre-processing the graph, to reduce the problem to a simpler problem. e.g. maybe trees can be contracted to points, or chains can be replaced with a single edge, or so on. these tricks are sometimes necessary to get scalable solution approaches in industrial applications of optimisation / OR methods to solve problems defined on graphs. a solution recovered on the simplified graph can be "trivially" extended back to the full original graph, given enough post-processing logic. if such graph simplifications make sense for your domain, can you preprocess and simplify your input graph until you hit a fixed point, then visualise the simplified result? (maybe it contracts to 1 node!)
I am not familiar with the job market in Germany, but here are a couple of comments based on what I have seen in Australia
Some large companies/organisations have an annual intake of graduates in a grad program. Some grad programs offer successful applicants a rotation through different areas of the business over a few years -- you get a lot of exposure to different areas of the business and can then decide something to specialise in.
There is a lot of opportunity in parts of IT, but you may be competing for entry-level roles against others who are recent software engineering graduates, or who are self-taught with strong examples from their own personal hobby projects or commercial software projects.
One way to get a foot in the door is indeed consulting, with a very likely downside of long days producing billable hours as you suggest. Consultancies are often keen to hire a batch of junior employees who may have no industry experience but are well-credentialed, have a lot of raw potential in terms of being clever with strong training in fundamentals, and can be billed to clients at attractive profit margins. If you can grit your teeth for a couple of years and regard working for a consultancy as a paid apprenticeship in gaining practical skills that are in demand by the market, that puts you in a position to transition into a better job with a better work/life balance and better pay.
If there's a range of consultancy jobs on offer I would suggest preferring a consultancy that specialises in a specific line of work that looks interesting and has a key mathematical aspect, rather than a consultancy that "specialises" in everything.
If you are looking to potentially transition into IT/software + some kind of domain-specific mathematical modelling, see if you can find a niche consultancy (or ideally a niche software business) advertising junior roles for clever people with maths backgrounds.
E.g. a small consultancy or business that does bespoke mathematical modelling + software solution projects for certain industries can be a great way to find interesting work and an environment where you can rapidly learn from more experienced colleagues.
> Keep reminding the team I need a review but only the tech lead actually reviews anything
idea i (less healthy):
maybe that gives you an angle -- if the tech lead is behaving like this with your other colleagues, maybe you can privately agree to review each other's PRs promptly, and cut the tech lead out of the review loop! starve the environment of unreviewed code stuck in limbo for your tech lead to steal, see what happens. this would be dysfunctional in a different way, but hey, a change is as good as a holiday, right?
idea ii (more healthy):
re: "reminding the team" to review PRs, a different way to do code reviews is "pick a victim". pick a specific non-tech-lead colleague and request that they review your PR. maybe roll a die or round-robin them to avoid picking the same colleague each time. that way the responsibility can't be diluted and you can hold a specific colleague accountable .
before you start doing this, you could call it out in a team meeting (standup? retro? having a chat around the coffee machine?) so everyone has a heads up that you're going to change things. you could even say something like "i've noticed that PRs sometimes get stuck in limbo for weeks without review. to spread out the review load, let's try having each PR author picking a specific person as the reviewer. pick a different person each time. if someone asks you to review, please leave a review in a day or call out if you're overloaded and need someone else to step up and review".
If the founder is in earshot and/or you get any pushback, you can say that spreading the review workload and working to get changes through review promptly should increase the velocity that the team is able to ship changes! This is (a) likely to be true, and (b) will make it much harder for someone to argue against what you're proposing, because shipping changes faster is what the founder wants.
are you / your team empowered to push back & decline being responsible for certain services that haven't cleared some minimum bar of stability? e.g. "if you want to put it into prod right away, we wont block you deploying it, but you'll be carrying the pager for it"
reply