> there’s a big difference between having ten years of experience and having one year of experience repeated ten times
Love this thought! It's surprisingly common to meet engineers with 6-7 years of experience with incredibly bad habits that they picked up working essentially at a single company that they joined right out of college. Repeating the same questionable patterns for 6 years doesn't provide a lot of growth opportunity. In this context, FAANG's obsession with hiring new grads is a questionable practice, people get stuck.
I've heard that exact same adage used in reverse by those "6-7 years at the same company" engineers against engineers with careers of shorter stints. The logic being that if you never experience 5/6/7+ years of continuous ownership, you never get to see how your decisions pan out, and you miss out on other forms of longitudinal experience.
If one thing is a constant, it is that engineers will always come up with these silly little adages and cliches to discount the experience of their peers and continue telling themselves they are the smartest kid in the room.
I will always value someone who has worked at 5 companies for 2 years each more than someone who has worked at the same company for 10 years. Most of the learning in any job happens during the first year. Imagine someone who has onboarded 5 times into 5 different company cultures and architectural systems. Such a person is a walking software engineering textbook.
As a farmer, I get years of experience. I only see about one crop grow each year, so it really takes decades to start to see patterns in the conditions the crops come up in (e.g. years of drought, years with little sunshine, years that are cold, etc.) with little in my control to change that schedule. Good management decisions require having an understanding of all of those patterns, and as such, a year is significant boundary.
But in software, the most significant boundary is how fast you can work. The faster you can work, the more scenarios you can try. Time is not completely removed from the equation, but two developers with different performance characteristics can have wildly different experience levels after an equal amount of time has passed. In this case, a year is not a significant boundary.
Don't work at megacorps where people are incentivized to ship big milestone branded projects and "quantifiable" impact because you will end up with massive codebases that are never refactored, over-engineered with such failures as code generation and abstract interfaces for everything, and keep layering on crap while tech debt entropy maximizes and relative agility grinds to a halt.
Agreed. Big tech is not were you learn good coding. There's no way they can recover from it. Most HR people there have no idea what they're doing and devs are all political and self-interest and it's probably full of foreign intelligence operatives who are interested in complexity as it helps them to hide backdoors all over the place.
Meta: I love this style of article and I wish it was more common and in more detail.
"How to build perfect software in Django" is incredibly hard to write, but "15 common Django architectural mistakes" is a lot easier to write is extremely useful.
IMO "15 common Django architectural mistakes" is a less useful focus for these types of posts. Architecture can't be taught by listing quick tips. Or at least not only by listing quick tips.
The unfortunate reality is that in many (most?) cases when inexperienced engineers face these challenges, it's too late to follow quick tips... their company's Django app has been set up 10 years prior, and now they have dozens upon dozens of layers of abstraction in the codebase.
Teaching how to think about architecture, how to evaluate options and how to make decisions is a more reliable and applicable skill.
Have we gone full circle? "10 hot tips for the perfect app" was a style that was so over used and clickbaity that HN rewrites the title to remove the count.
It's ironic that they use pictures of failing bridges, after describing software architecture practices which are never used to build bridges. Yes, let's experiment with this 300 million dollar bridge for a few years, and make sure the construction workers are part of defining the fill type and dimensions of the structural pillars.
The way I wish software were created is more like physical infrastructure. There's still huge problems with construction, to be sure. But it lasts longer and is more likely to succeed when completed. There's all kinds of requirements, analysis, and inspection to ensure it works correctly. The people putting it together don't need to be very skilled; they're working with off-the-shelf commodity parts, manufactured to a minimum specification, with specific dimensions and attributes, which loosely couple in many configurations with identical parts from different vendors all over the world. Combining them in specific ways has quantifiable, predetermined results. And you know that for the parts that require being designed correctly, the people designing them had very specific minimum qualifications that take years to attain.
Companies today, whenever they want to build a software product, think they need to build an entire factory first. But companies making physical products wouldn't do that, because building a factory requires factory-building skill, that has nothing to do with the widget they want to make. Instead they would find a factory and hire them to build their widget. Software may be "modern", but its production is antiquated.
I hear you, but the promise and curse of software is that it is malleable. We are not building bridges with extremely clear and obvious success and failure, we are creating user experiences that vary subjectively based on who is using them and what other digital or physical realities they interact with. It's an alluring fantasy that if we just let the seasoned experts design everything and gave them space to work, we could have better quality systems.
This is not how it plays out though, you get burned from both sides. Inevitably some non-technical leadership stakeholders ask very fair questions about "why can't we just...", and they're not wrong about what's possible, it's just different from what came before and it's not possible to rebuild entire digital systems as quickly as the good ideas come.
On the implementation side, details matter and abstractions leak, seemingly small requirement changes undermine assumptions behind major architectural decisions. The idea that you can have a handful of seasonsed experts guiding an army of low-skill builders just doesn't work out with the same economics of physical construction. The details matter too much, and the implications of pure logic are too diverse to be covered by the equivalent of physical building codes.
>The people putting it together don't need to be very skilled; they're working with off-the-shelf commodity parts, manufactured to a minimum specification, with specific dimensions and attributes, which loosely couple in many configurations with identical parts from different vendors all over the world.
Isn't this in some ephemeral way exactly what most of us do? Sure, there are people in the world doing real Computer Science(TM) but most of us are assembling apps from existing parts. Sure there's glue and there are domain specific bits, but there's a lot under the hood in both paid and open source forms aren't significantly different from going to a parts bin and pulling the right SKUs.
There are many failure modes, and by the time you show up... the entrenched incompetence will constrain the options within current project inertia and budgets.
Usually, it is better to branch a separate "new" team in another space, functionally deprecate the old project one feature at a time, and jettison the previous team including the manager after 6 months of uptime.
Trying to untangle a mess often takes 7 times longer than simply re-building a better version with well defined use-cases. =)
> by the time you show up... the entrenched incompetence will constrain the options within current project inertia and budgets.
this is so true, but sometimes the incompetence is so bad it's not feasible to build a competent team (very very difficult at least).
I'm actually in the middle of this now and I have to tell you, I've been doing this for 25+ years and I'm absolutely flabbergasted that people with this level of incompetence are gainfully employed in this industry. It's so bad we have contractor teams running circles around them and by circles I mean 2-3x their velocity with code designs that are as good or better.
> People who are not building the architecture should not make decisions about it.
Nope! Everyone can and does make mistakes. A good architect should accept and learn from suggestions and ultimately better technical decisions put forward by members of the team, whether it’s the senior with 70 years experience or the 1-month experience, bright junior with a good idea.
I was in a team where the architect chose to use React without TypeScript, and a nasty .NET 4/React mix for the front end. This was 2-3 years ago. I suppose it’s what he knew and was comfortable with? This combination caused no end of issues and an unnecessarily difficult development process. Unfortunately I wasn’t around at the time, but I’d have spoken up, and probably been listened to, which is what i’d expect from any good team, regardless of your position. Better is better, doesn’t matter whose mouth it comes out of.
A lot of the architects I’ve worked with have been rather snobby and quick to dismiss less experienced team members in my experience.
Unless your project complexity is on the order of blinking an LED, there isn't enough time in the day for a monolith, I'm afraid. You are going to have to build in coordination with other services (OSes, DMBSes, etc.)
? Article does not talk about pitfalls of architecture, proceeds to talk about hierarchical processes in organization. Guess it's a failure to uphold and implement layers of abstractions. Good thing there is a software engineer to distribute knowledge on software development process engineering. The failure of the article is the article.
From the context I assumed these are the things I knew as “non-functional requirements”. Basically, random stuff which doesn’t have specific associated use cases. Depending on the project, they might specify environment, setup and deployment, throughput and latency, system requirements, security, reliability, compliance, etc.
In systems design quality attributes are non-functional requirements that are used for the evaluation of the system itself rather than the intended behavior of the feature being implemented. E.g. system extensibility, scalability are quality attributes.
i used to work with these so called "software architects". they didnt ship any code but wrote articles like this at length that everyone pretended to read.
eg, I have worked with many so called 'developers'. They shipped lots of code, but most of it was solving the wrong problem, didn't fit any business requirement, added unnecessary complexity, had to be replaced almost immediately, etc. etc.
Shipping software means comprises but compromising everything will result in a failure.
You surely wouldn't argue that companies should compromise on developer machine specs, for example? Too many organisations cheap out somewhere on the development process in the name of "efficiency", and this article is arguing (and I agree) that that's short-sighted and will cause more trouble than it saves in the long run.
[+] [-] 1920musicman|2 years ago|reply
Love this thought! It's surprisingly common to meet engineers with 6-7 years of experience with incredibly bad habits that they picked up working essentially at a single company that they joined right out of college. Repeating the same questionable patterns for 6 years doesn't provide a lot of growth opportunity. In this context, FAANG's obsession with hiring new grads is a questionable practice, people get stuck.
[+] [-] CipherThrowaway|2 years ago|reply
If one thing is a constant, it is that engineers will always come up with these silly little adages and cliches to discount the experience of their peers and continue telling themselves they are the smartest kid in the room.
[+] [-] roncesvalles|2 years ago|reply
[+] [-] randomdata|2 years ago|reply
As a farmer, I get years of experience. I only see about one crop grow each year, so it really takes decades to start to see patterns in the conditions the crops come up in (e.g. years of drought, years with little sunshine, years that are cold, etc.) with little in my control to change that schedule. Good management decisions require having an understanding of all of those patterns, and as such, a year is significant boundary.
But in software, the most significant boundary is how fast you can work. The faster you can work, the more scenarios you can try. Time is not completely removed from the equation, but two developers with different performance characteristics can have wildly different experience levels after an equal amount of time has passed. In this case, a year is not a significant boundary.
[+] [-] mynameisnoone|2 years ago|reply
[+] [-] jongjong|2 years ago|reply
[+] [-] jamestimmins|2 years ago|reply
"How to build perfect software in Django" is incredibly hard to write, but "15 common Django architectural mistakes" is a lot easier to write is extremely useful.
[+] [-] 1920musicman|2 years ago|reply
The unfortunate reality is that in many (most?) cases when inexperienced engineers face these challenges, it's too late to follow quick tips... their company's Django app has been set up 10 years prior, and now they have dozens upon dozens of layers of abstraction in the codebase.
Teaching how to think about architecture, how to evaluate options and how to make decisions is a more reliable and applicable skill.
[+] [-] jayd16|2 years ago|reply
[+] [-] 0xbadcafebee|2 years ago|reply
The way I wish software were created is more like physical infrastructure. There's still huge problems with construction, to be sure. But it lasts longer and is more likely to succeed when completed. There's all kinds of requirements, analysis, and inspection to ensure it works correctly. The people putting it together don't need to be very skilled; they're working with off-the-shelf commodity parts, manufactured to a minimum specification, with specific dimensions and attributes, which loosely couple in many configurations with identical parts from different vendors all over the world. Combining them in specific ways has quantifiable, predetermined results. And you know that for the parts that require being designed correctly, the people designing them had very specific minimum qualifications that take years to attain.
Companies today, whenever they want to build a software product, think they need to build an entire factory first. But companies making physical products wouldn't do that, because building a factory requires factory-building skill, that has nothing to do with the widget they want to make. Instead they would find a factory and hire them to build their widget. Software may be "modern", but its production is antiquated.
[+] [-] dasil003|2 years ago|reply
This is not how it plays out though, you get burned from both sides. Inevitably some non-technical leadership stakeholders ask very fair questions about "why can't we just...", and they're not wrong about what's possible, it's just different from what came before and it's not possible to rebuild entire digital systems as quickly as the good ideas come.
On the implementation side, details matter and abstractions leak, seemingly small requirement changes undermine assumptions behind major architectural decisions. The idea that you can have a handful of seasonsed experts guiding an army of low-skill builders just doesn't work out with the same economics of physical construction. The details matter too much, and the implications of pure logic are too diverse to be covered by the equivalent of physical building codes.
[+] [-] poulsbohemian|2 years ago|reply
Isn't this in some ephemeral way exactly what most of us do? Sure, there are people in the world doing real Computer Science(TM) but most of us are assembling apps from existing parts. Sure there's glue and there are domain specific bits, but there's a lot under the hood in both paid and open source forms aren't significantly different from going to a parts bin and pulling the right SKUs.
[+] [-] Joel_Mckay|2 years ago|reply
Usually, it is better to branch a separate "new" team in another space, functionally deprecate the old project one feature at a time, and jettison the previous team including the manager after 6 months of uptime.
Trying to untangle a mess often takes 7 times longer than simply re-building a better version with well defined use-cases. =)
[+] [-] PH95VuimJjqBqy|2 years ago|reply
this is so true, but sometimes the incompetence is so bad it's not feasible to build a competent team (very very difficult at least).
I'm actually in the middle of this now and I have to tell you, I've been doing this for 25+ years and I'm absolutely flabbergasted that people with this level of incompetence are gainfully employed in this industry. It's so bad we have contractor teams running circles around them and by circles I mean 2-3x their velocity with code designs that are as good or better.
[+] [-] Arrgh|2 years ago|reply
[+] [-] supersparrow|2 years ago|reply
Nope! Everyone can and does make mistakes. A good architect should accept and learn from suggestions and ultimately better technical decisions put forward by members of the team, whether it’s the senior with 70 years experience or the 1-month experience, bright junior with a good idea.
I was in a team where the architect chose to use React without TypeScript, and a nasty .NET 4/React mix for the front end. This was 2-3 years ago. I suppose it’s what he knew and was comfortable with? This combination caused no end of issues and an unnecessarily difficult development process. Unfortunately I wasn’t around at the time, but I’d have spoken up, and probably been listened to, which is what i’d expect from any good team, regardless of your position. Better is better, doesn’t matter whose mouth it comes out of.
A lot of the architects I’ve worked with have been rather snobby and quick to dismiss less experienced team members in my experience.
[+] [-] fallingknife|2 years ago|reply
[+] [-] randomdata|2 years ago|reply
It is a nice idea, but totally impractical.
[+] [-] Log_out_|2 years ago|reply
[+] [-] bigEnotation|2 years ago|reply
[+] [-] Const-me|2 years ago|reply
[+] [-] 1920musicman|2 years ago|reply
[+] [-] jbmsf|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] theflork|2 years ago|reply
[+] [-] ubercow13|2 years ago|reply
eg, I have worked with many so called 'developers'. They shipped lots of code, but most of it was solving the wrong problem, didn't fit any business requirement, added unnecessary complexity, had to be replaced almost immediately, etc. etc.
[+] [-] mp05|2 years ago|reply
[+] [-] PH95VuimJjqBqy|2 years ago|reply
shipping software means compromise, most of these points are basically "don't compromise on X".
[+] [-] danparsonson|2 years ago|reply
You surely wouldn't argue that companies should compromise on developer machine specs, for example? Too many organisations cheap out somewhere on the development process in the name of "efficiency", and this article is arguing (and I agree) that that's short-sighted and will cause more trouble than it saves in the long run.