381–390 of 431 posts
Hard to disagree. I can usually tell what type of type of experience devs have by the snarky, dismissive responses I've gotten on various internet forums over the last two decades. e.g. "Oh but you would never have this problem if you performed proper code review" - Random_Rockstar_Dev_254 However not all legacy projects are bad to work on. If they're decently developed, then often you'll find that most of the pain i…
Earlier quoted context omitted.
I see that going through these three kinds of projects let me grow as a developer: 1. green field project 2. other people's legacy project 3. your green field project growing into legacy project. You can learn so much from each of these, but to me the most eye opening experience was our green field project growing into a project with more and more developers. You could learn so much about others, some were very arrog…
"3. your green field project growing into legacy project." You do all this upfront design about how it's going to work and then "Oh god there's so many splinters and sharp corners, it's only getting worse and every new team onboarded to the framework needs to have their hands held, and management won't allocate time to address the tech debt."
Earlier quoted context omitted.
Additionally, reading through other people's code is educational and it also builds self-esteem.
Conversely, reading through my own code from ancient history (>3 months ago) is both humbling and terrifying :D
Hard to disagree. I can usually tell what type of type of experience devs have by the snarky, dismissive responses I've gotten on various internet forums over the last two decades. e.g. "Oh but you would never have this problem if you performed proper code review" - Random_Rockstar_Dev_254 However not all legacy projects are bad to work on. If they're decently developed, then often you'll find that most of the pain i…
Earlier quoted context omitted.
And the only better experience than "working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions" is working on a second greenfield project long enough to see that drastically overcompensating for all the bad things from the first one is not the right solution either :)
I keep telling people v1 of anything always sucks. One of the tells of an inexperienced engineer I use is how much they disparage the previous team's work.
When your v1 code takes a company to profitability it was good enough.
By this logic I've been a senior engineer since I started working!
You’re not a senior engineer until you understand the difference between necessity and sufficiency.
Earlier quoted context omitted.
> very arrogant My experience, is that this is usually a defensive shell around personal insecurity. On the outside, it looks the same, but internally, insecure people can be reached (not easy), whereas truly arrogant folks (a lot more rare than you might think) cannot. My experience is that most difficult people are actually decent folks, that we can enjoy working with, but we need to adjust to them, and they need t…
> > very arrogant > a defensive shell around personal insecurity. could just be despair and honesty. I was reading about the kindle os here and wonder how many people are facing giant hairballs in their professional life. > the Kindle’s OS is a mess of Java, Javascript, Lua, Native and React Native code. ... > The Kindle runs stripped down Linux with a React Native frontend along with Java backend applications. https…
> The Kindle runs stripped down Linux with a React Native frontend along with Java backend applications.
Honest question: what exactly is wrong with this setup?
There's the OS, there are services and user land apps written in java and misc native code, and from the link there's a single component where Lua was used as bridge code.
The GUI is React Native, which is just a framework to simplify the design and implementation of native GUIs.
So exactly what's wrong?
Earlier quoted context omitted.
Engineering isn't about working on the most interesting problems. It's about getting stuff done and management happy. Here, parent explained in detail how to get stuff done, management very happy and secure their position for years to come.
Engineers have a special place in society like doctors and lawyers. Working with management is part of the job, but engineers have a professional ethical obligation to say no if they are asked to something against the public good. The split there isn’t in favor of doing stuff that’s fun and novel though; actually, the engineer should usually pick a boring proven solution if the public has a high stake in the outcome.
But the vast majority of HN topics are not concerned. Additionaly, it does not pay well
Earlier quoted context omitted.
This is literally the approach recommended in Team Topologies. The same team should own vN and vN+1, so that they both have to operate their own design and have the opportunity not to make the same mistakes again. It should be the default.
That would require staying in one company for more than 2 years, which means you probably lost out on 20-30% of income over next 2 years.
Hard to disagree. I can usually tell what type of type of experience devs have by the snarky, dismissive responses I've gotten on various internet forums over the last two decades. e.g. "Oh but you would never have this problem if you performed proper code review" - Random_Rockstar_Dev_254 However not all legacy projects are bad to work on. If they're decently developed, then often you'll find that most of the pain i…
> I can usually tell what type of type of experience devs have by the snarky, dismissive responses I've gotten on various internet forums over the last two decades. I see this constantly on HN and have had to learn to not engage with those conversations. It is like some people have never had to run a project under any sort of external constraints like head count restrictions, layoffs, inheriting a system which you di…