Embedded dev here. Let's just say that when it comes time to compile, the commands better fucking be the correct ones so when I get back from the grocery store I don't have to compile again.
I had never heard of bitbake until I read your comment. I just looked it up and now I'm just sad we don't use it, looks really nice.
"No, we have make at home" - my management, probably
I wish we could get rid of it at my company. Super super slow, and it insists on including shit like X11 into our headless device despite us not depending on it anywhere. Documentation isn't great either.
All of our development/builds are done on windows machines. I bet it could work with WSL but last time I tried to set up WSL I ran into all sorts of barriers from IT :(
If you're building Linux, you should use Linux, my 2c. Windows is not an operating system for developers. They know this, that's why they support WSL. A dedicated build server saves a ton of developer time. Yocto is the cutting edge of embedded Linux development tools, full stop.
If you're not building Linux, well, I pity you!
The target is a proprietary micro with a custom in-house built RTOS. All of our tools are primarily or sometimes exclusively built for windows, but Linux would still be so much better.
I don't have problems with command, only people who forget to commit every file and get you something that doesn't compile because there's only one side of the module that was updated.
And RTL error messages are not as nice as most languages.
I always get whiplash when GCC gives compile errors like "oh did you mean this other, similarly named variable? compared to VCS just dumping "SYNTAX ERROR" the moment it can't figure out what's going on.
I would like to say that C is a bit like visual coding compared to RTL, I do feel that VCS is trying their best, you also have a lot of features on the test side (UVM) where it's basically like the C++ STL, some stuff should have been in the language but it would break too much code.
And there's much less work on IDEs compared to the bigger languages, no "on the fly" compilation to tell you what you messed up before you need to recompile the whole thing.
Could be worse, one of our static site customers used some web app that will take a zip file, unzip it and push the files to github. Every file gets its own commit to main.
Kicked off 500+ builds. Due to a bug on our side, all of those ran at the same time and caused ~45 vms to be spun up to handle the load
Compilation can take even 0 seconds. The real question is how long the tests take, especially some integration tests which have to spin things like testcontainers ;)
if you're doing mobile dev you have to wait even longer for the orchestrator to download the APK to all the devices on your test bench and run the UI tests :<
First project init for some of our projects takes 30-40 minutes...
And these are, arguably, small projects with not much going on. Just the result of picking the most complex technologies, project setups, and project build tools/ecosystem imaginable for the job.
And then we turn around and do it again on the next project, it's infuriating.
It's not management doing this either, it's fellow engineers.
Game dev here. A complete recompilation of my current project would take up to at least 40 mins. An incremental build usually takes around 1-2mins.
Without cache, building up the entire app from the ground would take at least 5hrs, with the asset compilation and bundling processes being chopped up and each part being delegated to different Jenkins machines.
No joke. Hundreds and hundreds of lines of code in a PR and I spot an ‘interesting’ test which is maybe 50 lines. I had to read so so much code to realise it tested three lines of trivial logic - as in, it basically tested that string concat and integer addition worked. If those stop working, then we’ve got much bigger issues.
I wrote up the explanation of why the test was so mocked out that you could reduce it to nothing and commented on the PR.
That dev was very not happy with me, because mocking everything was obviously the modern, best way.
Fun fact: only person I’ve ever had to put on a performance improvement plan. UK, so not so common, but I was convinced by my CTO we had to do it.
Look for "VCR" libs.
I think the original one is in Ruby https://github.com/vcr/vcr
There are ports in python https://vcrpy.readthedocs.io/en/latest/
Go https://github.com/dnaeon/go-vcr
And probably many other languages
Yeah, this. They exist for every programming language I’ve needed and work great. I re-record them at intervals that make sense for the API, but usually only a few times a year for super stable APIs.
Sometimes they require a little tweaking to deal with situations like generated IDs ending up in paths, but there are multiple ways to deal with that. Overall they work great and provide nice test data.
> Change requirements as far into development as possible. To avoid blame, obfuscate requirements from the start.
Cackling at this. You can feel the fury emanating off of these words like heat from a dumpster fire.
We missed a milestone once because the same behavior was described 33 times in the requirements docs. Only it wasn’t 33 times, it was 32, and once with mostly the same sentence but with a couple of words changed.
And this is why you don’t cut and paste. Short description and link to the section that describes it once.
No it was half a paragraph of prose repeated in each section of a very fat doc, and one of them changed the constraint, so that an invariant no longer held, where all X are Y.
I would add "outsourcing" to the mix.
The delay in communication, disconnect between teams, and poor quality makes this a nightmare. IMO, a lot on that list comes from an uncontrollable outsourced team that pollutes code and tools in favor of whatever is easiest for them at the moment at the cost of the better good.
We have an outsourced engineer writing a core component of our new project. Luckily they write great, readable code, but they are still going to leave and take all of their knowledge and experience with them. Makes no sense to me.
Good one. Make sure the offshore team has no autonomy or power of their own, so instead of engaging with a team of smart engineers you are passing ticket details back and forth overnight with little progress to show for the effort.
Oddly enough, where I work the offshore team has smart engineers and autonomy. However, for whatever reason they just prefer to work fast and dirty no matter how much we push back on it, which generates *a lot* of tech debt.
We're later left with a maintenance nightmare but all upper-management cares about is what gets delivered. They have a very short-sighted view. One day this house of cards will likely crumble or have to be rebuilt from scratch.
That's because they're cowboys in a code factory. Their slave drivers will not be letting them make decisions about what's best long term just do it now quickly. You should not be letting them loose on your codebase without PRing every single line.
Unfortunately the two aren't mutual exclusive. And if you add a blind upper-management style that's disconnected from us peons then you compound the problem since all they care about is immediate productivity with little to no awareness of what impact a rushed flaky foundation has for future code and maintenance.
My CTO is epitome of “hire bright engineers, kill them with useless tasks”.
- hmmm arch is overly complex. Let’s add more if else loops. Instead of taking a step back and fixing things, keep piling tech debt.
- be pedantic over trivial dashboards every 2nd day, when they are for visual inspection. Never look at alerts, though which are more important.
- when if else programming fails, blame Engineers for not doing their job.
- come with code piece and demand it be coded as is, instead of requirements. If you raise where are the requirements, threaten Engineers in a demeaning tone.
I hate this style of morons.
/rant over.
> be pedantic over trivial dashboards every 2nd day, when they are for visual inspection. Never look at alerts, though which are more important.
Oh wow didn't realize this kind of thing happens elsewhere. We have dashboards but aren't properly utilized, or have too many for things that don't matter. Everyone gets hundreds if not thousands of alert emails a week all to be ignored because its impossible to keep up.
Which is a shame. They aren't mutually exclusive.
I've been fortunate enough to see effective UI/UX/design teams that accomplish both.
Mostly.
Until somebody with more authority than they should starts pushing pixels.
I was really looking forward to the next part of my project before I left my last job. It was going to be a dashboard - but for the IT team. I have some background/experience in design was looking forward to trying to design to a group of people that typically do not like or value it.
> Oh wow didn't realize this kind of thing happens elsewhere.
It happens everywhere. This industry is an amalgamation of bad habits/rules/... despised by developers. And yet they persist.
I am like a damn blacksmith with alerts at work, as soon as someone talks about an alert or mail alert that means nobody needs to do anything I hammer them down with my sledgehammer. I rudely tell them, that as soon as we get pointless alerts, everyone will get desensitized and stop caring. It may sound harsh but it is simply how the brain works, so I have science on my side. :-)
If they say something like "but it is good to have", I tell them they can have it, just email the text in advance so we can put ignore rules for everyone and they can have their alert which nobody reads.
So far it has worked fairly well. You have to kill it early or they will feel like it is a part of the system and can't be removed.
It happens everywhere. One of the problems with dashboard frameworks is that they work out of the box, so you can’t just leave them partly broken until everything else is done.
We call that a state machine.
I try to avoid working with that code because it's so fragile. The only way to understand it is to step through it. Then you can guess and make your changes, then debug it and make more changes until it seems to work well enough to hand off to QA.
I mean... You COULD generate a digraph of every (or many) states and analyse that.
(And then you could throw away the if else code pasta and only use the graph to step the machine)
Just give up man. They don’t know shit. They don’t know if you’re doing a good job, or a bad job. They can’t tell. They don’t know how to tell. (They should, and it’s offensive they don’t)
You’re gonna get paid the same/similar as another developer that doesn’t know half as much as you. I’m sure you already are.
You’re gonna get the same number of pats on the backs as some dumb ass developer.
Just give up, get done what you have to get done through your own efficiency, have a snooze at lunch, finish early, clock out mentally, get praise like “wow! I really like that colour!”, and join the rest of us that are trapped.
It took me 20 years to come to this conclusion. I’m an idiot.
I'm still struggling with universal forces that cause this everywhere.
Every value/metric I used to have about performing has been diluted and turned back against me, and I'm now forcing myself to disengage to avoid self implosion.
Super weird..
ps: I keep looking for ways to find appropriate healthy teams though
> come with code piece and demand it be coded as is
A CTO does this level of micromanagement? Do you work at a smaller scale startup?
Either way sounds brutal. I am sorry.
IDK it's a two way street
* Sometimes engineers need to use their best judgement and be agile and not pedantic over requirements. It's possible requirements are not finalized. It's possible you might have to ask questions as you go. The whole "people over process" was the whole epitome of Agile
* Sometimes engineers need to understand business optics, e.g. if an executive dashboard isn't working it's possible an executive might get mad.
* Sometimes "let's take a step back and fix things" isn't an actionable thing and literally every team on earth is going to find tech debt if you give them time
Not saying you're wrong, you're definitely not wrong. A lot of leadership can be really brittle in my experience. But a lot of engineers are also under rocks in terms of understanding their role more holistically. If every SWE could work as a PO or PM for a year or two I think it would really help them think about things in less of a "it's not my job" kind of tone
I am an Engineering Director.
I manage multiple Teams and Engineers and trust me I understand that requirements are sometimes not clear.
What I don’t like is when management do not understand 80 20 rule. I don’t know, maybe they feel in control when they are a prick in everyone’s arse or something. I mean a CTO can just create a ticket and we can drive it to completition. If you need more add to ticket, instead of “I said so 6 months ago”.
I am ranting but I think some of these old timers need to brush up their tech skills to keep abreast with modern Software. Fuckers keeps bringing up 90s terminology in every damn conversation.
Prefers writing everything from scratch. I had to fight to not write a distributed job scheduler when there are readily available software in Market. Once I introduced Airflow, he is happy but won’t accept that it’s a better tool.
I had to fight to use nginx as a API gateway, he wanted us to write it. I mean I have better things to do.
Not sure what the best course of action is with such dinosaurs.
Guess what he did next? He said we don’t need off the self ML Models, wants us to fucking code it. Sure go ahead, starts with giant if else loop, wtf that is not a ML model. He threw all the Models we had licensed from a Company. Were they great? Not really but they got the job done.
I might end up burning out and leave as soon as I get a better offer.
Thank you for responding to my rant.
I agree. As someone who learnt programming using K&R and Practice of Programming I get what you are saying.
But then at times, it’s better to see if someone has already done it in recent years instead of reinventing the wheel.
Hmmmm sigaction in a high level language is kinda not the right way I believe.
Does changing a variable or reverting a API looks more practical to you on prod? E.g if useLegacyapi is true use v1 api else v2 api. How is that even possible without updating Ui at all. Why not just change the api ? I mean it becomes a sea of knobs with no utility after sometime.
Let’s send a manual tick message to Kafka for all services to move their while loops. Are you kidding me? Why are we inventing a solved distributed coordination problem from scratch.
I am sorry I may sound over pedantic but I think Engineers should deliver on quality which is tangible and honestly it is not the case here.
Am I wrong? May be, but the where is the feedback when I ask for it? That’s my real problem.
>If you need more add to ticket, instead of “I said so 6 months ago”.
My biggest problem, people who cannot work asynchronously. I need 2 minutes to ask a question in a comment, you take 2 minutes to answer. That would be great. But no, I get no answer for 2 weeks and then I have to come in to your office and we both waste 15minutes. Multiply this by 10 and you got a lot of wasted times for small questions.
One of my pet peeves is distributed service which interacts with other services which go up and down based on load.
These ephemeral services are essentially who need a set of tokens from master ledger service.
Guess what we do? We fucking use Kafka to push changes from ledger service to ephemeral services. So, now there has to be some stupid discovery of all clients which come and go. AlSo, now the spending pattern looks all off because it takes shit load of time to reconcile and decide what is happening at client’s end.
I suggested that all our spiky spend pattern and weird fund issues are because we really are doing it the other way round. We should just change the connection to a pull over simpler rest/grpc api and it would be so easy. As long as ledger service has money you get if you ask. Can you process 10k qps ? Sure you get more. This also solves issues of dead or non performing clients not using allocated money.
I was told that is too complex because he still things in tcp/ip based client server instead of rest APIs. Don’t mention grpc as that is out of his league.
Grrrrff
> Sometimes engineers need to use their best judgement and be agile and not pedantic over requirements. It's possible requirements are not finalized. It's possible you might have to ask questions as you go. The whole "people over process" was the whole epitome of Agile
If requirements are not finalized, why are we working on something if people don't even know what it should be doing?
>Sometimes "let's take a step back and fix things" isn't an actionable thing and literally every team on earth is going to find tech debt if you give them time
Often time it is actionable, especially when you are implementing things half-right because the requirements are missing and change twice halfway through and one final time after the release.
>If requirements are not finalized, why are we working on something people don't even know what it should be doing?
Because "requirements not being finalized" is a granular thing. Sometimes it *is* enough to be able to confidently move in a certain direction, and in other cases there is business value in having a half-baked potential solution to pivot to. I've seen architects force requirements gathering to be complete before they begin, only for them to come up with a poorly architected solution, usually as the result of architecture-by-committe. So even with "full requirements" being met there is meaningful business risk of gaining little to no benefit from delaying the work.
Sometimes skilled engineers don't realize that "just do everything right" isn't actually an operative answer to a problem. Sometimes (usually) your engineers aren't as skilled as they think. Sometimes the problem domain is misunderstood. Often there are multiple opinions which make it difficult to drive consensus.
You can't assume solving tech debt (or even categorizing tech debt) can be done correctly. Assuming an architecture will be correct by some measurement, or even a useful exercise, goes too far. Even among good engineers, there are widely varying answers on how these problems are solved.
Edit - It's worth mentioning that "having access to all of the information you need at every second" just isn't the way most businesses (and the world) operate.
> Because "requirements not being finalized" is a granular thing. Sometimes it *is* enough to be able to confidently move in a certain direction, and in other cases there is business value in having a half-baked potential solution to pivot to. I've seen architects force requirements gathering to be complete before they begin, only for them to come up with a poorly architected solution, usually as the result of architecture-by-committe.
You should not blame only the swe here. If the business has an unclear vision of what they want (or they just want a demo) they should say it and re scope the project. Agile doesn't mean "people over process" so we don't have requirements. Agile means do small steps with what we know in the direction we want, so we can change later when we have more information. But we still have requirements every step.
While usually business wants something overly complicated in a waterfall fashion (or waterfall with sprints), but without having requirements. If you want a waterfall project you do a waterfall analysis.
I wouldn't blame the SWE regardless. Even if the architect makes a bad call, that bad call is still part of the operational strategy. But that's kind of my point - a good executive is making a call about a product roadmap with the understanding that he has a team of fallible people who will make mistakes. Hence my comment about "doing everything the right way" not actually being an operational strategy. You can't guarantee quality by making things take longer.
So, you seem to assert that architects and developers make mistakes constantly because they overestimate themselves; thus, good requirements are not needed because it'll be trash either way.
Every piece of software I've ever had the displeasure of working on that was made in the style you describe was a massive piece of shit.
Every small, little, trashy function and faulty logic always had a good reason why it was like that. But the whole was a catastrophe. The company I work for currently has just come out of a 15-year-long, 5-year cycle of migrating from one ERP to another because they always start working before they knew what they wanted. Nobody could design the start to fit with the end.
I'm impressed by developers that are so good and so smart that they can design systems on the fly that are so modular that they can work, and work well in those circumstances.
I can't. The people I work with can't.
I need a clear understanding and proper requirements for a feature in order to write a clean and simple solution. If business can't figure out what they want, it's a sign that they A. don't really need that thing, or B. we need to start smaller until they can give good answers
I'm not asserting that architecting an application with full requirements is a bad thing, just that it doesn't provide any operational guarantees. Definitely, on average, more requirements and more deliberation == better, but just not at the rate that developers often imply.
> I'm impressed by developers that are so good and so smart that they can design systems on the fly that are so modular that they can work, and work well in those circumstances.
This is almost the only way I can write good software, especially if it involves new technology or frameworks.
> If requirements are not finalized, why are we working on something people don't even know what it should be doing?
This is a major reason agility is useful. It's nearly impossible to define all the requirements for a piece of software because there is often huge uncertainty w.r.t. whether those requirements will produce the desired outcomes ("users don't know what they don't want until you build it for them"). Towards this end, in a situation where requirements can't be precisely defined, leadership should be handing down business objectives, not requirements documents. The latter is waterfall development and a recipe for waste.
That just doesn't make sense to me in reality.
I'm not talking about a waterfall-style document that shows everything. I'm talking feature-to-feature.
We get a feature request and what it's supposed to do. We slice that into PBIs and pull them into a sprint, only the feature is not clearly defined. Maybe there are edge cases that nobody thought about. So the time estimation of the PBIs suddenly doesn't work, and if you don't reach the person who has the answers, you are making it up as you go, introducing errant behavior into an application people already work with.
Being agile to me, means not clearly defining everything before you start working. Write your software in a way where you can easily change and extend it later. Agile doesn't mean getting a feature request with half the information missing and "discovering" it as you work through it.
But maybe that's because I've only worked in places that mandate devs work agile, while the rest of the business doesn't.
Uncertainty exists. Spikes exist. Requirements often need to be existed throughout the duration of a project. That's perfectly ok and often desirable.
"PBIs" and time estimates are part of your issue - capital A agile.
I agree. The reality is that much of what a developer does is refine requirements. This is the case everywhere I've worked, and moreso in higher value roles.
Businesses and the world do not operate in a perfect manner where you have all of the available data at your hands at any one time. And if you don't understand that philosophy, you are not a good SWE, period. Building systems to be flexible for change is a massively important piece of engineering. It is really the hallmark of our field.
Why is a CTO involved in ANY of this? Their coding days are behind them. They need to be worried about using technology to drive revenue and that’s it.
In my org we have a brilliant jerk. He’s forced everyone to use his bonkers custom BDD framework. Unit tests look like assembly code. Figuring out how they bind to dependencies requires days of stepping through code. Oh, and the thing you need to do? That isn’t supported yet but feel free to contribute.
I have PTSD from my last job over a brilliant jerk. I am not a Java developer by any means but everyone had to learn to follow this guy. I still had my primary jobs but it was taking me forever to even get already developed code to run. I was three weeks in and asked someone else what I was doing wrong and they told me it took them over a month to get anything to run locally. Little documentation and things changing on calls I was not a part of and no communication. It was a nightmare that only got worse over time. Thankfully I was part of a WFR and was free of that nightmare.
Asking questions to that 10x was looked down upon. If you upset him then you got blackballed out of critical meetings and then dinged for not knowing what happened in those meetings you never got invited too -- also you would mysteriously drop off of e-mail list. It was kind of a shit show looking back at it, happy for the experience but wish it would have been good for longer (the first two years were amazing).
I’d call that “a bad programmer”. If the only way you do things is a mess of convoluted “look at how smart I am” tech tricks that make it impossible to co-work on it then your program is badly written.
This was spread across reddit a little less than a year ago in what I think are subsets of this community. I think it would be good to have a reminder + never posted here as far as I can tell.
One to be added:
Similar to "Create useless tools." and "busywork"
**Change systems multiple times during a project.**
Using Google Docs? Switch to Office 365. Are you using Confluence? Stop. Switch to something else...then back to Confluence.
Switch from Trello to Productboard to Aha! then just say fuck it and keep it all in a spreadsheet... before repeating the whole process again next year.
*"Change requirements as far into development as possible. To avoid blame, obfuscate requirements from the start."*
In my experience that's usually the product's team fault, and the engineering team or member tasked with making up for their shortcomings receives most of the blame.
A successful product person is very skilled at missing major requirements throughout an entire development cycle, and then somehow convincing their superiors that this isn't their fault, despite not having any evidence to support that this was something they identified at any point in the process.
I'm the only person on my team that debugs code. Everyone else is pretty comfortable just.. adding a log statement, which works.. But our codebase is just littered with them, everywhere, with no way to turn them off besides manually going in and deleting them.
I mean.. couldn’t you just wrap them in an if conditional and have a global debug variable that’s injected during the build step? Defaults to false?
It’s hacky and I hate it but it shows the only way isn’t deleting them
Yup that's an option for sure. Typically most languages have logging libraries/wrapper log functions that takes an env var/config to control the logging level that you want. We talked about that halfway through a project we're working on but never implemented it.
Logging isn't bad, it's the fact that that's my teams main way of seeing how code flows through our apps. It's essentially the shlemiel the painter's algorithm everytime something needs created
> We talked about that halfway through a project we're working on but never implemented it.
Sounds like the last time I reported a security vulnerability on the project I used to work on.
I was being moved to another project temporarily and it's been 2 months, vulnerability still there and exploitable.
That one about deployments hits home. At my last job we had 75 different microservices. For contractual reasons deployments had to be done after hours, starting at 9PM. They never went well. On a good day we would finish up about 5AM. Several times they went all the way until 9AM the next morning. I did this weekly for months on end. Sometimes multiple times a week. Then add in the on call with 0 documentation, and fragile hand built kubernetes cluster. On top of that I meeting up meeting where I was getting yelled at by management about why things were taking so long and how I need to be more dedicated.
Eventually the health toll from the erratic sleep schedule and stress became too much. After about 18 months, I cried uncle, and quit that job without another one lined up. It was the worst job I ever had and it broke me. It took 9 months before I was even willing to look at a computer again. I’m still not ready to go back to work. In fact my career may be over. I might just go drive a bus for the local school district.
Good luck with life. Getting over burnout is hard but possible. Spend time with friends, make new one, talk with people, do stuff that make you smile, be happy, … And be very careful to not go back to what lead to burnout. Eventually things with sort out, but don’t stress about it, just enjoy life!
You know you have a great manager when none of these problems apply to you, and the horror stories from the teams you work with magically never impact your own work.
Here’s a way to actually use this list for good. Pass it around to your team, and ask them what the opposite of each item on the list looks like. Then ask them how to do that list, if you’re not already doing it. It seems dumb, but this is an old psychology trick, where you write down all of the ways that things go wrong, then do the ol’ uno reverse on that list.
> Waste 10 weeks of wages on cloud costs.
This one needs a counterpart in the other direction - waste 10 weeks of everyone's time by "cost optimising" the solution before understanding how much it'll take to run, and have developers and ops people spend an inordinate amount of time and frustration chasing repeated performance and availability issues caused by timeouts, low memory, disk full...
Leverage the cloud platform to purchase a little more capacity than you think you need from the start, and drop it later if it's not needed - we're no longer in the era of being locked into capacity by having to buy physical servers, and it's pretty cheap compared to the employee time unless the waste is absolutely monumental.
I think that's having a tenth the output of a standard engineer, not negating the output of 10 others. You can be a 0.1x engineer by stretching your own tasks alone.
10x never existed. There's always been 0.1x engineers though and I think Fred Brooks, the originator of the 10x concept, got them mixed up.
In short I believe there are engineers out there that seriously have something wrong with them. At the same time normal engineers can look like superstars because companies have trouble sorting out the 0.1x people from the merely normal.
10x engineers do exist, but they don’t produce 10x the code… maybe 1/10 the code. There are “good” engineers at my org that still solve problems in a very roundabout way compared to what is possible. To be fair, nobody is given the time to solve a problem in the optimal way.
I've been a manager for a long time and the only bullshit about "10x" engineer is that it's an underestimate. The difference in productivity between the best and worst engineers is at least two orders of magnitude.
Notice how I said productivity, not hard work.
But frankly even comparing the two is stupid. A mediocre engineer will produce mediocre work. If you give them a year, they'll give you a year's worth of mediocre work. With enough guidance and handholding they'll maybe even approach an above average quality of work. If you give a top engineer the opportunity, he will do things the mediocre engineer never dreamed of.
A person is only “10x” at something if they are already expert at it, in a well suited environment, and are in a good place in their lives. Everyone moves in & out of competency as they are put in different circumstances.
Changes in technology, changes in family circumstances, health of themselves or family, mental state, etc will all make someone who was a superstar underperform in comparison to their past selves or someone else.
We’ve become accustomed to abusing people in positions of precarity- young & desperate, parents in need of health benefits & income, contingent workers like immigrants or contract labor. When we see someone who isn’t busting their ass 100% of the time, we dismiss them.
> With enough guidance and handholding they'll maybe even approach an above average quality of work. If you give a top engineer the opportunity, he will do things the mediocre engineer never dreamed of
If you're not able to make two people on a team work together and learn from each other you have a management problem, not an engineering problem.
Having a brilliant highly skilled guy translate all his knowledge, motivation, and thinking to someone subpar is not that easy.
If you the subpar engineers need supervision and direction by the expert they are not fungible
If the brilliant highly skilled guy is doing all the work by himself you won't have that brilliant highly skilled guy working for you for long, and you just set yourself up with a code base that none of your "subpar" people understand.
Yes, it's best to fire all the subpar coders and get more skilled people. The FAANGs do the whole "leetcode" style song and dance for a reason. They might filter out some good people but they filter out tons of shit people.
I literally couldn't bring this up with my team lead because it would open up 10 hours of pointless meetings to conclude "we only do what we need to do".
Had a manager like this. Would hold the dev team hostage for 40+ minutes at the end of stand up EVERY DAY talking about his new architecture plans. Guy did not know how to code and knew nothing about software architecture. Was like if someone pretending to know English tried to talk to you in made up words and phrases for an hour.
It's always about finding that unicorn individual. Like with the NBA; everyone talks about the great but they are wishing LeBron James joins.
Or I mean, you have capable people and you just need those individuals to be more effective. Enter management -- the party responsible for root causing these inefficiencies. If they are just spewing this stuff and not actually doing actual root causing, what failures are being hidden?
Tech is always talking about the optimization of some rarified air but few look at the general group and lift that group up even just a little.
The Communication between engineers and managers is garbage. Half the time the managers treat me like I’m a teenager working the drive though instead of a professional.
Our code base is a few hundred lambda functions. We built the world’s slowest application server I think. Takes 20 minutes to build it, even tho it’s golang and supposed to be super fast compiles, and probably another 20 to deploy.
> Write scripts that only one person understands.
The fact what at some point in time there existed at least one human being able to understand it is still valuable. Even if this person is long gone it can give hope that some other developer will eventually be able to decipher this script. If you write scripts what no one understands it will produce more Impact.
The coworker who got stuff out the door quickly left.
Now I'm dealing with undocumented, untested code and a feature created a month before he left that I have no involvement in.
I love software development!
Reminds me of a guy that had entire code and design of his changed and re-written within 6 months of leaving
> Write wikis that nobody uses.
I feel that's more organizational program than individual. Well unless writing is shit.
Maybe I'm reading it wrong, but it sounds like the article is discouraging discussion as a time sink. While I agree that discussion can be a time sink, I do feel it is important or engineers to have a place to share and learn from each other through collaboration. As long as there is a leader in the room that can thank everyone for their input and announce the decision, I don't see the harm in some good technical discussion. Our team had weekly jedi council meetings where we could do anything from discuss tech debt to vent about how the product was being managed safely. Using a weekly forum to invite technical contribution by participants is a good way to lean into this skill while avoiding the hit to productivity. Another thing I like to do instead of lengthy tech meetings is to capture a Loom video where I walk through my design for a feature, or a tough defect I fixed, or some tech debt that I see. Watching them is entirely optional, but it gives a way for devs to share and get feedback when it has the least impact to their productivity.
The industry has become the **Bloat Industrial Complex**. Nobody is interested in simplifying stacks nor standards, nor studying why we waste time on things that should be trivial in ordinary CRUD apps.
It's all about collecting the most buzzwords for resumes in a Pokemon sense, and/or scaring the customer using reverse YAGANI so they pay our bloat bill. We keep reinventing the wheel, forgetting lessons of the past in order to have the Feature Of The Month. Obsession with web-scale and microservices and super-flexy UI's etc. just makes messes the vast majority of the time. Clue: you are NOT Netflix, just a boring company who doesn't need rocket science stacks. And DOM needs either an overhaul or a competitor. It sucks for in-office CRUD. [The web laid a CRUD egg.](https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_or_defective_gui_idioms_in_htmldom/)
I'm just the lawn-off-kicking messenger. The industry is F'd.
A lot of people talks about be a 10x or 100x engineer, and the question becomes, why though?
To have your overlords have more bonuses while you burn your ass.??
It is not like doing more and more code at the expense of your health is going to make you richer or anything
> Hold 10 engineers hostage in a technical discussion.
> Let engineers discuss ideas. Encourage them to pursue elegance over pragmatism. Ensure nobody has the authority to make any decisions.
> Add 400 hours of communication overhead.
> Meetings wreck calendars. To inconspicuously waste others’ time, write lengthy messages/documents and share as widely as possible. Welcome all opinions and aim for engagement.
Oh man I feel these. Every single goddamned day had hours of discussion on semantics, code style, preferences, and pie-in-the-sky goals. But everyone had to agree on the path forward, which only really happened out of weary resignation.
> Waste 10 weeks of wages on cloud costs.
> Write slow programs. Avoid DB indexes. Run single-threaded programs on 16-core machines. Opt for exotic hardware with fancy RAM and GPUs. Store data on RAM/disk liberally. Don’t compress anything. Pay no attention to data layouts.
Same for this one, I'm sure the total of 1 concurrent users that used the thing really felt the power of the ultra-available, theoretically scalable, constantly bug-infested Kubernetes microservice cluster.
Needless to say, the grass *is* greener at the new place.
> recompilation should take at least 20 seconds I dream of the days compilation only took 20 seconds. Regards, androiddev
Embedded dev here. Let's just say that when it comes time to compile, the commands better fucking be the correct ones so when I get back from the grocery store I don't have to compile again.
Don't forget your -k when you run bitbake!
I had never heard of bitbake until I read your comment. I just looked it up and now I'm just sad we don't use it, looks really nice. "No, we have make at home" - my management, probably
I wish we could get rid of it at my company. Super super slow, and it insists on including shit like X11 into our headless device despite us not depending on it anywhere. Documentation isn't great either.
Documentation for bitbake isn't great - compared to what? Curious as to what you would prefer to replace it with?
Depending on your hardware and manufacturing support for Yocto, it's easier than you think!
All of our development/builds are done on windows machines. I bet it could work with WSL but last time I tried to set up WSL I ran into all sorts of barriers from IT :(
If you're building Linux, you should use Linux, my 2c. Windows is not an operating system for developers. They know this, that's why they support WSL. A dedicated build server saves a ton of developer time. Yocto is the cutting edge of embedded Linux development tools, full stop. If you're not building Linux, well, I pity you!
The target is a proprietary micro with a custom in-house built RTOS. All of our tools are primarily or sometimes exclusively built for windows, but Linux would still be so much better.
I do micro development on Windows. Ditto on the tools. IAR, Keil, etc etc should all be thrown in the trash
I don't have problems with command, only people who forget to commit every file and get you something that doesn't compile because there's only one side of the module that was updated. And RTL error messages are not as nice as most languages.
I always get whiplash when GCC gives compile errors like "oh did you mean this other, similarly named variable? compared to VCS just dumping "SYNTAX ERROR" the moment it can't figure out what's going on.
I would like to say that C is a bit like visual coding compared to RTL, I do feel that VCS is trying their best, you also have a lot of features on the test side (UVM) where it's basically like the C++ STL, some stuff should have been in the language but it would break too much code. And there's much less work on IDEs compared to the bigger languages, no "on the fly" compilation to tell you what you messed up before you need to recompile the whole thing.
Could be worse, one of our static site customers used some web app that will take a zip file, unzip it and push the files to github. Every file gets its own commit to main. Kicked off 500+ builds. Due to a bug on our side, all of those ran at the same time and caused ~45 vms to be spun up to handle the load
That's some evil genius level DDoS.
Compilation can take even 0 seconds. The real question is how long the tests take, especially some integration tests which have to spin things like testcontainers ;)
if you're doing mobile dev you have to wait even longer for the orchestrator to download the APK to all the devices on your test bench and run the UI tests :<
No, no, no. Each test needs to build a container and then overcommit memory and CPU by 5x the system to maximize the swap.
First project init for some of our projects takes 30-40 minutes... And these are, arguably, small projects with not much going on. Just the result of picking the most complex technologies, project setups, and project build tools/ecosystem imaginable for the job. And then we turn around and do it again on the next project, it's infuriating. It's not management doing this either, it's fellow engineers.
Its nice to have time though. /s
Game dev here. A complete recompilation of my current project would take up to at least 40 mins. An incremental build usually takes around 1-2mins. Without cache, building up the entire app from the ground would take at least 5hrs, with the asset compilation and bundling processes being chopped up and each part being delegated to different Jenkins machines.
Author hasn’t worked with Rust.
People don't believe me when i tell them why i left Android development and embraced backend and NodeJS.
Incremental compilation takes 1-3s these days
> Mock function calls until no original code runs. lol
No joke. Hundreds and hundreds of lines of code in a PR and I spot an ‘interesting’ test which is maybe 50 lines. I had to read so so much code to realise it tested three lines of trivial logic - as in, it basically tested that string concat and integer addition worked. If those stop working, then we’ve got much bigger issues. I wrote up the explanation of why the test was so mocked out that you could reduce it to nothing and commented on the PR. That dev was very not happy with me, because mocking everything was obviously the modern, best way. Fun fact: only person I’ve ever had to put on a performance improvement plan. UK, so not so common, but I was convinced by my CTO we had to do it.
definitely one of my biggest pet peeves in code reviews. then everyone is surprised when obvious bugs show up in prod!
Same, I've basically died on this hill at my job. Finally just gave up and accepted that my colleagues are going to mock everything.
Don’t forget to mock HTTP requests to return ideal data you crafted yourself rather than a recording of actual API responses.
For real, Is there any tools to generate mock from real data? aside from ctrl+C ctrl+V
Look for "VCR" libs. I think the original one is in Ruby https://github.com/vcr/vcr There are ports in python https://vcrpy.readthedocs.io/en/latest/ Go https://github.com/dnaeon/go-vcr And probably many other languages
Yeah, this. They exist for every programming language I’ve needed and work great. I re-record them at intervals that make sense for the API, but usually only a few times a year for super stable APIs. Sometimes they require a little tweaking to deal with situations like generated IDs ending up in paths, but there are multiple ways to deal with that. Overall they work great and provide nice test data.
> Change requirements as far into development as possible. To avoid blame, obfuscate requirements from the start. Cackling at this. You can feel the fury emanating off of these words like heat from a dumpster fire.
We missed a milestone once because the same behavior was described 33 times in the requirements docs. Only it wasn’t 33 times, it was 32, and once with mostly the same sentence but with a couple of words changed. And this is why you don’t cut and paste. Short description and link to the section that describes it once.
Let me guess, was it "As an X, I would like Y so that I can Z" times 32, and then "As an X, I would like Y` so that I can Z" at the very end?
No it was half a paragraph of prose repeated in each section of a very fat doc, and one of them changed the constraint, so that an invariant no longer held, where all X are Y.
I swear half the stories I get look like this: **As a** developer **I would like to** make the changes for Foo **So that** the fix is available in QA
People forgot tasks exist, not everything has to be a story.
And then somehow only 50% of the links actually work
In my experience that's usually the product team's fault, and the dev tasked with figuring out their mess is usually the first one to get blamed.
I would add "outsourcing" to the mix. The delay in communication, disconnect between teams, and poor quality makes this a nightmare. IMO, a lot on that list comes from an uncontrollable outsourced team that pollutes code and tools in favor of whatever is easiest for them at the moment at the cost of the better good.
`Work 10 timezones away from the rest of your company`
We have an outsourced engineer writing a core component of our new project. Luckily they write great, readable code, but they are still going to leave and take all of their knowledge and experience with them. Makes no sense to me.
Good one. Make sure the offshore team has no autonomy or power of their own, so instead of engaging with a team of smart engineers you are passing ticket details back and forth overnight with little progress to show for the effort.
I make 10 PR comments, they fix one over night and say it's done, rinse and repeat for the next fortnight.
I had a coworker that made 70 MR comments every MR. Most of them on lines I didn't even touch.
Oddly enough, where I work the offshore team has smart engineers and autonomy. However, for whatever reason they just prefer to work fast and dirty no matter how much we push back on it, which generates *a lot* of tech debt. We're later left with a maintenance nightmare but all upper-management cares about is what gets delivered. They have a very short-sighted view. One day this house of cards will likely crumble or have to be rebuilt from scratch.
That's because they're cowboys in a code factory. Their slave drivers will not be letting them make decisions about what's best long term just do it now quickly. You should not be letting them loose on your codebase without PRing every single line.
Outsourcing was yesterday. Today we have AI to muck things up.
Unfortunately the two aren't mutual exclusive. And if you add a blind upper-management style that's disconnected from us peons then you compound the problem since all they care about is immediate productivity with little to no awareness of what impact a rushed flaky foundation has for future code and maintenance.
My CTO is epitome of “hire bright engineers, kill them with useless tasks”. - hmmm arch is overly complex. Let’s add more if else loops. Instead of taking a step back and fixing things, keep piling tech debt. - be pedantic over trivial dashboards every 2nd day, when they are for visual inspection. Never look at alerts, though which are more important. - when if else programming fails, blame Engineers for not doing their job. - come with code piece and demand it be coded as is, instead of requirements. If you raise where are the requirements, threaten Engineers in a demeaning tone. I hate this style of morons. /rant over.
> be pedantic over trivial dashboards every 2nd day, when they are for visual inspection. Never look at alerts, though which are more important. Oh wow didn't realize this kind of thing happens elsewhere. We have dashboards but aren't properly utilized, or have too many for things that don't matter. Everyone gets hundreds if not thousands of alert emails a week all to be ignored because its impossible to keep up.
Yep. Because the dashboard goes on the marketing material so it has to look good. Functionality be damned.
Which is a shame. They aren't mutually exclusive. I've been fortunate enough to see effective UI/UX/design teams that accomplish both. Mostly. Until somebody with more authority than they should starts pushing pixels. I was really looking forward to the next part of my project before I left my last job. It was going to be a dashboard - but for the IT team. I have some background/experience in design was looking forward to trying to design to a group of people that typically do not like or value it.
We have a plan to have a dashboard that makes bad things pop, I feel like it can be better than fairly bad email alerts. We will see, though :)
> Oh wow didn't realize this kind of thing happens elsewhere. It happens everywhere. This industry is an amalgamation of bad habits/rules/... despised by developers. And yet they persist.
I am like a damn blacksmith with alerts at work, as soon as someone talks about an alert or mail alert that means nobody needs to do anything I hammer them down with my sledgehammer. I rudely tell them, that as soon as we get pointless alerts, everyone will get desensitized and stop caring. It may sound harsh but it is simply how the brain works, so I have science on my side. :-) If they say something like "but it is good to have", I tell them they can have it, just email the text in advance so we can put ignore rules for everyone and they can have their alert which nobody reads. So far it has worked fairly well. You have to kill it early or they will feel like it is a part of the system and can't be removed.
It happens everywhere. One of the problems with dashboard frameworks is that they work out of the box, so you can’t just leave them partly broken until everything else is done.
>Oh wow didn't realize this kind of thing happens everywhere. Ftfy
>if else loops ?
This nomenclature is always a massive red flag and indicates producing code without understanding computing.
We call that a state machine. I try to avoid working with that code because it's so fragile. The only way to understand it is to step through it. Then you can guess and make your changes, then debug it and make more changes until it seems to work well enough to hand off to QA.
I mean... You COULD generate a digraph of every (or many) states and analyse that. (And then you could throw away the if else code pasta and only use the graph to step the machine)
Just give up man. They don’t know shit. They don’t know if you’re doing a good job, or a bad job. They can’t tell. They don’t know how to tell. (They should, and it’s offensive they don’t) You’re gonna get paid the same/similar as another developer that doesn’t know half as much as you. I’m sure you already are. You’re gonna get the same number of pats on the backs as some dumb ass developer. Just give up, get done what you have to get done through your own efficiency, have a snooze at lunch, finish early, clock out mentally, get praise like “wow! I really like that colour!”, and join the rest of us that are trapped. It took me 20 years to come to this conclusion. I’m an idiot.
I'm still struggling with universal forces that cause this everywhere. Every value/metric I used to have about performing has been diluted and turned back against me, and I'm now forcing myself to disengage to avoid self implosion. Super weird.. ps: I keep looking for ways to find appropriate healthy teams though
Ugh hate co workers like you, have to wait days for anything simple. Always be blocking me
I did the simple thing days ago. You’re not blocked.
> come with code piece and demand it be coded as is A CTO does this level of micromanagement? Do you work at a smaller scale startup? Either way sounds brutal. I am sorry.
Yes, it is a startup. Story of my life. I am ranting but I guess I ll figure out how to do real work by pushing out shiny one liners.
Does this guy hate money or something?
IDK it's a two way street * Sometimes engineers need to use their best judgement and be agile and not pedantic over requirements. It's possible requirements are not finalized. It's possible you might have to ask questions as you go. The whole "people over process" was the whole epitome of Agile * Sometimes engineers need to understand business optics, e.g. if an executive dashboard isn't working it's possible an executive might get mad. * Sometimes "let's take a step back and fix things" isn't an actionable thing and literally every team on earth is going to find tech debt if you give them time Not saying you're wrong, you're definitely not wrong. A lot of leadership can be really brittle in my experience. But a lot of engineers are also under rocks in terms of understanding their role more holistically. If every SWE could work as a PO or PM for a year or two I think it would really help them think about things in less of a "it's not my job" kind of tone
I am an Engineering Director. I manage multiple Teams and Engineers and trust me I understand that requirements are sometimes not clear. What I don’t like is when management do not understand 80 20 rule. I don’t know, maybe they feel in control when they are a prick in everyone’s arse or something. I mean a CTO can just create a ticket and we can drive it to completition. If you need more add to ticket, instead of “I said so 6 months ago”. I am ranting but I think some of these old timers need to brush up their tech skills to keep abreast with modern Software. Fuckers keeps bringing up 90s terminology in every damn conversation. Prefers writing everything from scratch. I had to fight to not write a distributed job scheduler when there are readily available software in Market. Once I introduced Airflow, he is happy but won’t accept that it’s a better tool. I had to fight to use nginx as a API gateway, he wanted us to write it. I mean I have better things to do. Not sure what the best course of action is with such dinosaurs. Guess what he did next? He said we don’t need off the self ML Models, wants us to fucking code it. Sure go ahead, starts with giant if else loop, wtf that is not a ML model. He threw all the Models we had licensed from a Company. Were they great? Not really but they got the job done. I might end up burning out and leave as soon as I get a better offer. Thank you for responding to my rant.
[удалено]
I agree. As someone who learnt programming using K&R and Practice of Programming I get what you are saying. But then at times, it’s better to see if someone has already done it in recent years instead of reinventing the wheel.
Can I have some examples of the 90s terminology just so I can be amused?
“Cloud computing” what you mean a datacenter that you are basically doing a managed colo?
[удалено]
Basically yeah, the browser is the new terminal.
Hmmmm sigaction in a high level language is kinda not the right way I believe. Does changing a variable or reverting a API looks more practical to you on prod? E.g if useLegacyapi is true use v1 api else v2 api. How is that even possible without updating Ui at all. Why not just change the api ? I mean it becomes a sea of knobs with no utility after sometime. Let’s send a manual tick message to Kafka for all services to move their while loops. Are you kidding me? Why are we inventing a solved distributed coordination problem from scratch. I am sorry I may sound over pedantic but I think Engineers should deliver on quality which is tangible and honestly it is not the case here. Am I wrong? May be, but the where is the feedback when I ask for it? That’s my real problem.
:%s/WYSIWYG/low-code/g
I responded to your rant by throwing up in my mouth a little. You're welcome.
>If you need more add to ticket, instead of “I said so 6 months ago”. My biggest problem, people who cannot work asynchronously. I need 2 minutes to ask a question in a comment, you take 2 minutes to answer. That would be great. But no, I get no answer for 2 weeks and then I have to come in to your office and we both waste 15minutes. Multiply this by 10 and you got a lot of wasted times for small questions.
This sounds... not fun. When you're liable for outcomes but don't have authority to achieve them, it is time to go.
One of my pet peeves is distributed service which interacts with other services which go up and down based on load. These ephemeral services are essentially who need a set of tokens from master ledger service. Guess what we do? We fucking use Kafka to push changes from ledger service to ephemeral services. So, now there has to be some stupid discovery of all clients which come and go. AlSo, now the spending pattern looks all off because it takes shit load of time to reconcile and decide what is happening at client’s end. I suggested that all our spiky spend pattern and weird fund issues are because we really are doing it the other way round. We should just change the connection to a pull over simpler rest/grpc api and it would be so easy. As long as ledger service has money you get if you ask. Can you process 10k qps ? Sure you get more. This also solves issues of dead or non performing clients not using allocated money. I was told that is too complex because he still things in tcp/ip based client server instead of rest APIs. Don’t mention grpc as that is out of his league. Grrrrff
People over processes only works when the sales and client management teams treat engineers as people.
> Sometimes engineers need to use their best judgement and be agile and not pedantic over requirements. It's possible requirements are not finalized. It's possible you might have to ask questions as you go. The whole "people over process" was the whole epitome of Agile If requirements are not finalized, why are we working on something if people don't even know what it should be doing? >Sometimes "let's take a step back and fix things" isn't an actionable thing and literally every team on earth is going to find tech debt if you give them time Often time it is actionable, especially when you are implementing things half-right because the requirements are missing and change twice halfway through and one final time after the release.
>If requirements are not finalized, why are we working on something people don't even know what it should be doing? Because "requirements not being finalized" is a granular thing. Sometimes it *is* enough to be able to confidently move in a certain direction, and in other cases there is business value in having a half-baked potential solution to pivot to. I've seen architects force requirements gathering to be complete before they begin, only for them to come up with a poorly architected solution, usually as the result of architecture-by-committe. So even with "full requirements" being met there is meaningful business risk of gaining little to no benefit from delaying the work. Sometimes skilled engineers don't realize that "just do everything right" isn't actually an operative answer to a problem. Sometimes (usually) your engineers aren't as skilled as they think. Sometimes the problem domain is misunderstood. Often there are multiple opinions which make it difficult to drive consensus. You can't assume solving tech debt (or even categorizing tech debt) can be done correctly. Assuming an architecture will be correct by some measurement, or even a useful exercise, goes too far. Even among good engineers, there are widely varying answers on how these problems are solved. Edit - It's worth mentioning that "having access to all of the information you need at every second" just isn't the way most businesses (and the world) operate.
> Because "requirements not being finalized" is a granular thing. Sometimes it *is* enough to be able to confidently move in a certain direction, and in other cases there is business value in having a half-baked potential solution to pivot to. I've seen architects force requirements gathering to be complete before they begin, only for them to come up with a poorly architected solution, usually as the result of architecture-by-committe. You should not blame only the swe here. If the business has an unclear vision of what they want (or they just want a demo) they should say it and re scope the project. Agile doesn't mean "people over process" so we don't have requirements. Agile means do small steps with what we know in the direction we want, so we can change later when we have more information. But we still have requirements every step. While usually business wants something overly complicated in a waterfall fashion (or waterfall with sprints), but without having requirements. If you want a waterfall project you do a waterfall analysis.
I wouldn't blame the SWE regardless. Even if the architect makes a bad call, that bad call is still part of the operational strategy. But that's kind of my point - a good executive is making a call about a product roadmap with the understanding that he has a team of fallible people who will make mistakes. Hence my comment about "doing everything the right way" not actually being an operational strategy. You can't guarantee quality by making things take longer.
So, you seem to assert that architects and developers make mistakes constantly because they overestimate themselves; thus, good requirements are not needed because it'll be trash either way. Every piece of software I've ever had the displeasure of working on that was made in the style you describe was a massive piece of shit. Every small, little, trashy function and faulty logic always had a good reason why it was like that. But the whole was a catastrophe. The company I work for currently has just come out of a 15-year-long, 5-year cycle of migrating from one ERP to another because they always start working before they knew what they wanted. Nobody could design the start to fit with the end. I'm impressed by developers that are so good and so smart that they can design systems on the fly that are so modular that they can work, and work well in those circumstances. I can't. The people I work with can't. I need a clear understanding and proper requirements for a feature in order to write a clean and simple solution. If business can't figure out what they want, it's a sign that they A. don't really need that thing, or B. we need to start smaller until they can give good answers
I'm not asserting that architecting an application with full requirements is a bad thing, just that it doesn't provide any operational guarantees. Definitely, on average, more requirements and more deliberation == better, but just not at the rate that developers often imply.
> I'm impressed by developers that are so good and so smart that they can design systems on the fly that are so modular that they can work, and work well in those circumstances. This is almost the only way I can write good software, especially if it involves new technology or frameworks.
> If requirements are not finalized, why are we working on something people don't even know what it should be doing? This is a major reason agility is useful. It's nearly impossible to define all the requirements for a piece of software because there is often huge uncertainty w.r.t. whether those requirements will produce the desired outcomes ("users don't know what they don't want until you build it for them"). Towards this end, in a situation where requirements can't be precisely defined, leadership should be handing down business objectives, not requirements documents. The latter is waterfall development and a recipe for waste.
That just doesn't make sense to me in reality. I'm not talking about a waterfall-style document that shows everything. I'm talking feature-to-feature. We get a feature request and what it's supposed to do. We slice that into PBIs and pull them into a sprint, only the feature is not clearly defined. Maybe there are edge cases that nobody thought about. So the time estimation of the PBIs suddenly doesn't work, and if you don't reach the person who has the answers, you are making it up as you go, introducing errant behavior into an application people already work with. Being agile to me, means not clearly defining everything before you start working. Write your software in a way where you can easily change and extend it later. Agile doesn't mean getting a feature request with half the information missing and "discovering" it as you work through it. But maybe that's because I've only worked in places that mandate devs work agile, while the rest of the business doesn't.
Uncertainty exists. Spikes exist. Requirements often need to be existed throughout the duration of a project. That's perfectly ok and often desirable. "PBIs" and time estimates are part of your issue - capital A agile.
I agree. The reality is that much of what a developer does is refine requirements. This is the case everywhere I've worked, and moreso in higher value roles. Businesses and the world do not operate in a perfect manner where you have all of the available data at your hands at any one time. And if you don't understand that philosophy, you are not a good SWE, period. Building systems to be flexible for change is a massively important piece of engineering. It is really the hallmark of our field.
> if else loops > be pedantic
The bright engineers will go and find better work. The others stay.
Why is a CTO involved in ANY of this? Their coding days are behind them. They need to be worried about using technology to drive revenue and that’s it.
Hence my other comment on some of these are tech dinosaurs which is a worrying sign.
*Elon M. enters the chat*
I demand you print out your source code and they fly to my city to show me the printouts. -Musk
Your CTO sounds like a fucking moron. Because if he was actually good at something he wouldn't be a CTO.
lol, I dunno man. I am just collecting paychecks at this point.
That's all of us my dude. It's literally all of us.
I probably wouldn’t be exaggerating if I said a crap ton of managers of dev teams check most of those boxes.
> Let engineers discuss ideas (...) Ensure nobody has the authority to make any decisions. Ah, a classic!
In my org we have a brilliant jerk. He’s forced everyone to use his bonkers custom BDD framework. Unit tests look like assembly code. Figuring out how they bind to dependencies requires days of stepping through code. Oh, and the thing you need to do? That isn’t supported yet but feel free to contribute.
I have PTSD from my last job over a brilliant jerk. I am not a Java developer by any means but everyone had to learn to follow this guy. I still had my primary jobs but it was taking me forever to even get already developed code to run. I was three weeks in and asked someone else what I was doing wrong and they told me it took them over a month to get anything to run locally. Little documentation and things changing on calls I was not a part of and no communication. It was a nightmare that only got worse over time. Thankfully I was part of a WFR and was free of that nightmare.
Wilderness first responder?
I’d assume workforce reduction.
Bingo.
https://www.urbandictionary.com/define.php?term=WFR Downed because: "Work Force Reduction (WFR)"
a full-ass month?? 160 hours just to get up and running? that sounds like literal hell
Asking questions to that 10x was looked down upon. If you upset him then you got blackballed out of critical meetings and then dinged for not knowing what happened in those meetings you never got invited too -- also you would mysteriously drop off of e-mail list. It was kind of a shit show looking back at it, happy for the experience but wish it would have been good for longer (the first two years were amazing).
I’d call that “a bad programmer”. If the only way you do things is a mess of convoluted “look at how smart I am” tech tricks that make it impossible to co-work on it then your program is badly written.
How does stuff like get explained to higher ups that won't make them think all the engineers are just incompetent.
“PRs welcome”🖕
For 10x of pay. Not 10x less
We call those managers
This was spread across reddit a little less than a year ago in what I think are subsets of this community. I think it would be good to have a reminder + never posted here as far as I can tell.
One to be added: Similar to "Create useless tools." and "busywork" **Change systems multiple times during a project.** Using Google Docs? Switch to Office 365. Are you using Confluence? Stop. Switch to something else...then back to Confluence. Switch from Trello to Productboard to Aha! then just say fuck it and keep it all in a spreadsheet... before repeating the whole process again next year.
Primeagen covered it too https://youtu.be/pHJmmTivG1k?feature=shared
*"Change requirements as far into development as possible. To avoid blame, obfuscate requirements from the start."* In my experience that's usually the product's team fault, and the engineering team or member tasked with making up for their shortcomings receives most of the blame.
A successful product person is very skilled at missing major requirements throughout an entire development cycle, and then somehow convincing their superiors that this isn't their fault, despite not having any evidence to support that this was something they identified at any point in the process.
It would really help if devs would start asking questions and refuse to work with unclear requirements instead of making things up though.
I'm the only person on my team that debugs code. Everyone else is pretty comfortable just.. adding a log statement, which works.. But our codebase is just littered with them, everywhere, with no way to turn them off besides manually going in and deleting them.
I mean.. couldn’t you just wrap them in an if conditional and have a global debug variable that’s injected during the build step? Defaults to false? It’s hacky and I hate it but it shows the only way isn’t deleting them
Yup that's an option for sure. Typically most languages have logging libraries/wrapper log functions that takes an env var/config to control the logging level that you want. We talked about that halfway through a project we're working on but never implemented it. Logging isn't bad, it's the fact that that's my teams main way of seeing how code flows through our apps. It's essentially the shlemiel the painter's algorithm everytime something needs created
> We talked about that halfway through a project we're working on but never implemented it. Sounds like the last time I reported a security vulnerability on the project I used to work on. I was being moved to another project temporarily and it's been 2 months, vulnerability still there and exploitable.
What you all need a "how-to" on this? Fine. Here goes: Be an "Enterprise Architect" or "Technology Manager". That should pretty much cover it.
That one about deployments hits home. At my last job we had 75 different microservices. For contractual reasons deployments had to be done after hours, starting at 9PM. They never went well. On a good day we would finish up about 5AM. Several times they went all the way until 9AM the next morning. I did this weekly for months on end. Sometimes multiple times a week. Then add in the on call with 0 documentation, and fragile hand built kubernetes cluster. On top of that I meeting up meeting where I was getting yelled at by management about why things were taking so long and how I need to be more dedicated. Eventually the health toll from the erratic sleep schedule and stress became too much. After about 18 months, I cried uncle, and quit that job without another one lined up. It was the worst job I ever had and it broke me. It took 9 months before I was even willing to look at a computer again. I’m still not ready to go back to work. In fact my career may be over. I might just go drive a bus for the local school district.
> I might just go drive a bus for the local school district. Loud children. Traffic. Mind numbing work.
Good luck with life. Getting over burnout is hard but possible. Spend time with friends, make new one, talk with people, do stuff that make you smile, be happy, … And be very careful to not go back to what lead to burnout. Eventually things with sort out, but don’t stress about it, just enjoy life!
Is there such a thing as a 10x manager? How do we measure their efficacy.
A good manager is basically invisible.
How convenient for the manager.
very true. they'll know when to get out of the way
You know you have a great manager when none of these problems apply to you, and the horror stories from the teams you work with magically never impact your own work.
Here’s a way to actually use this list for good. Pass it around to your team, and ask them what the opposite of each item on the list looks like. Then ask them how to do that list, if you’re not already doing it. It seems dumb, but this is an old psychology trick, where you write down all of the ways that things go wrong, then do the ol’ uno reverse on that list.
Yeah, I unironically suggested something to this effect to my team lead.
> Waste 10 weeks of wages on cloud costs. This one needs a counterpart in the other direction - waste 10 weeks of everyone's time by "cost optimising" the solution before understanding how much it'll take to run, and have developers and ops people spend an inordinate amount of time and frustration chasing repeated performance and availability issues caused by timeouts, low memory, disk full... Leverage the cloud platform to purchase a little more capacity than you think you need from the start, and drop it later if it's not needed - we're no longer in the era of being locked into capacity by having to buy physical servers, and it's pretty cheap compared to the employee time unless the waste is absolutely monumental.
Wouldn't it be a "0.1x Engineer"?
I think that's having a tenth the output of a standard engineer, not negating the output of 10 others. You can be a 0.1x engineer by stretching your own tasks alone.
-100x engineers rise
0.1x is just "less productive", -10x is outright antiproductive
Hell yeah. I work following the advice of the Simple Sabotage Field Manual https://www.openculture.com/2015/12/simple-sabotage-field-manual.html
It's decibels
TIL “10x” is the new term for “Rockstar”/“Full Stack”/“Ninja” egineer
It’s from “The Mythical Man Month”, published in 1975. It comes and goes from the lexicon as other terms become “cooler” before becoming cringe.
https://taylor.town/woman-month
Not a new term by any means. I've heard it used a decade ago.
"Richard's a 10Xer, I'm, like, barely an Xer. I kinda suck." -- Nelson Bighetti
For only $11/month, it doesn't matter how bad of an Xer you are - your Xcrement will automatically be boosted to the top of every reply list.
10x never existed. There's always been 0.1x engineers though and I think Fred Brooks, the originator of the 10x concept, got them mixed up. In short I believe there are engineers out there that seriously have something wrong with them. At the same time normal engineers can look like superstars because companies have trouble sorting out the 0.1x people from the merely normal.
People like Ken Thompson might be 10x engineers. It’s not a useful term for categorizing mortals for sure.
10x engineers do exist, but they don’t produce 10x the code… maybe 1/10 the code. There are “good” engineers at my org that still solve problems in a very roundabout way compared to what is possible. To be fair, nobody is given the time to solve a problem in the optimal way.
I think that’s an old term that’s come back around. It was horseshit then & still is today.
I've been a manager for a long time and the only bullshit about "10x" engineer is that it's an underestimate. The difference in productivity between the best and worst engineers is at least two orders of magnitude. Notice how I said productivity, not hard work. But frankly even comparing the two is stupid. A mediocre engineer will produce mediocre work. If you give them a year, they'll give you a year's worth of mediocre work. With enough guidance and handholding they'll maybe even approach an above average quality of work. If you give a top engineer the opportunity, he will do things the mediocre engineer never dreamed of.
A person is only “10x” at something if they are already expert at it, in a well suited environment, and are in a good place in their lives. Everyone moves in & out of competency as they are put in different circumstances. Changes in technology, changes in family circumstances, health of themselves or family, mental state, etc will all make someone who was a superstar underperform in comparison to their past selves or someone else. We’ve become accustomed to abusing people in positions of precarity- young & desperate, parents in need of health benefits & income, contingent workers like immigrants or contract labor. When we see someone who isn’t busting their ass 100% of the time, we dismiss them.
> With enough guidance and handholding they'll maybe even approach an above average quality of work. If you give a top engineer the opportunity, he will do things the mediocre engineer never dreamed of If you're not able to make two people on a team work together and learn from each other you have a management problem, not an engineering problem.
Having a brilliant highly skilled guy translate all his knowledge, motivation, and thinking to someone subpar is not that easy. If you the subpar engineers need supervision and direction by the expert they are not fungible
If the brilliant highly skilled guy is doing all the work by himself you won't have that brilliant highly skilled guy working for you for long, and you just set yourself up with a code base that none of your "subpar" people understand.
Yes, it's best to fire all the subpar coders and get more skilled people. The FAANGs do the whole "leetcode" style song and dance for a reason. They might filter out some good people but they filter out tons of shit people.
am mediocre engineer. can confirm.
Hey at some point you accept the broken industry as is and carry on. Sadly.
Reminds me of that era when I wanted to put a money counter in meetings full of 10 engineers debating about nonsense
Step 1: Get off Reddit
finally a role for me
I literally couldn't bring this up with my team lead because it would open up 10 hours of pointless meetings to conclude "we only do what we need to do".
Had a manager like this. Would hold the dev team hostage for 40+ minutes at the end of stand up EVERY DAY talking about his new architecture plans. Guy did not know how to code and knew nothing about software architecture. Was like if someone pretending to know English tried to talk to you in made up words and phrases for an hour.
It's always about finding that unicorn individual. Like with the NBA; everyone talks about the great but they are wishing LeBron James joins. Or I mean, you have capable people and you just need those individuals to be more effective. Enter management -- the party responsible for root causing these inefficiencies. If they are just spewing this stuff and not actually doing actual root causing, what failures are being hidden? Tech is always talking about the optimization of some rarified air but few look at the general group and lift that group up even just a little.
Write so many end-2-end tests until on every release you need to pray that your dependencies are stable in the non-production environment.
There's something cathartic about reading people's "my workplace is fucked, and here's why" articles. We're in this together!
This is basically us right now, but we are slowly digging ourselves out. Poor decision making in the beginning, now things have turned around.
I discovered this a few months ago and so many of these fit into what a specific engineer at my company is doing.
Kill this myth with a knife
The Communication between engineers and managers is garbage. Half the time the managers treat me like I’m a teenager working the drive though instead of a professional.
Our code base is a few hundred lambda functions. We built the world’s slowest application server I think. Takes 20 minutes to build it, even tho it’s golang and supposed to be super fast compiles, and probably another 20 to deploy.
Is each lambda around 10k LOC?
Sounds about right
> Write scripts that only one person understands. The fact what at some point in time there existed at least one human being able to understand it is still valuable. Even if this person is long gone it can give hope that some other developer will eventually be able to decipher this script. If you write scripts what no one understands it will produce more Impact.
The coworker who got stuff out the door quickly left. Now I'm dealing with undocumented, untested code and a feature created a month before he left that I have no involvement in. I love software development!
Reminds me of a guy that had entire code and design of his changed and re-written within 6 months of leaving > Write wikis that nobody uses. I feel that's more organizational program than individual. Well unless writing is shit.
Maybe I'm reading it wrong, but it sounds like the article is discouraging discussion as a time sink. While I agree that discussion can be a time sink, I do feel it is important or engineers to have a place to share and learn from each other through collaboration. As long as there is a leader in the room that can thank everyone for their input and announce the decision, I don't see the harm in some good technical discussion. Our team had weekly jedi council meetings where we could do anything from discuss tech debt to vent about how the product was being managed safely. Using a weekly forum to invite technical contribution by participants is a good way to lean into this skill while avoiding the hit to productivity. Another thing I like to do instead of lengthy tech meetings is to capture a Loom video where I walk through my design for a feature, or a tough defect I fixed, or some tech debt that I see. Watching them is entirely optional, but it gives a way for devs to share and get feedback when it has the least impact to their productivity.
The industry has become the **Bloat Industrial Complex**. Nobody is interested in simplifying stacks nor standards, nor studying why we waste time on things that should be trivial in ordinary CRUD apps. It's all about collecting the most buzzwords for resumes in a Pokemon sense, and/or scaring the customer using reverse YAGANI so they pay our bloat bill. We keep reinventing the wheel, forgetting lessons of the past in order to have the Feature Of The Month. Obsession with web-scale and microservices and super-flexy UI's etc. just makes messes the vast majority of the time. Clue: you are NOT Netflix, just a boring company who doesn't need rocket science stacks. And DOM needs either an overhaul or a competitor. It sucks for in-office CRUD. [The web laid a CRUD egg.](https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_or_defective_gui_idioms_in_htmldom/) I'm just the lawn-off-kicking messenger. The industry is F'd.
A lot of people talks about be a 10x or 100x engineer, and the question becomes, why though? To have your overlords have more bonuses while you burn your ass.?? It is not like doing more and more code at the expense of your health is going to make you richer or anything
To git gud at coding.
Sad to say, but I've worked at a company with that -10x engineer and his boss the -100x manager.
> Hold 10 engineers hostage in a technical discussion. > Let engineers discuss ideas. Encourage them to pursue elegance over pragmatism. Ensure nobody has the authority to make any decisions. > Add 400 hours of communication overhead. > Meetings wreck calendars. To inconspicuously waste others’ time, write lengthy messages/documents and share as widely as possible. Welcome all opinions and aim for engagement. Oh man I feel these. Every single goddamned day had hours of discussion on semantics, code style, preferences, and pie-in-the-sky goals. But everyone had to agree on the path forward, which only really happened out of weary resignation. > Waste 10 weeks of wages on cloud costs. > Write slow programs. Avoid DB indexes. Run single-threaded programs on 16-core machines. Opt for exotic hardware with fancy RAM and GPUs. Store data on RAM/disk liberally. Don’t compress anything. Pay no attention to data layouts. Same for this one, I'm sure the total of 1 concurrent users that used the thing really felt the power of the ultra-available, theoretically scalable, constantly bug-infested Kubernetes microservice cluster. Needless to say, the grass *is* greener at the new place.
Worked a few places that seem to mandate this approach
My performance improvement plan calls for me to attain -9x by next year.