5 ms·

Don't put it together. Learn all this stuff, understand it deeply. Then use it when you find it improves whatever you are working on. If you start putting it a

Don't put it together. Learn all this stuff, understand it deeply. Then use it when you find it improves whatever you are working on. If you start putting it all together you will most likely only confuse other developers, especially juniors. Don't do it. The point of gathering all this knowledge should be making the application simpler and easier to maintain. So introduce stuff gradually and only when you find the added complexity pays out.

thdespou 4y ago
This is probably a syndrome of overhyped lead developers trying to "engineer" a solution without consulting with the team beforehand. They read a bunch of articles, decide that it's the "best" solution and blend everything together in a soup of tools that don't make sense. I've seen that happening many times with bad results every time.
- twawaaay 4y ago
  Yeah... for some reason developers think that the higher position/salary requires them to put forward more complicated solution. Nothing further from the truth. My goal in life is to learn so that I can engineer systems and write code that is as simple as possible. It takes a bit of courage to put forward code that looks like everybody could write it -- which is exactly the point of getting more mature in software development. One problem I always had is that managers seem to reward people for how complicated projects they are working on rather than reward for putting in effort into making things simple. This makes a bit of conflict of interest but I personally resolved to do what is right and feel good with myself rather than to play the silly game of who can overcomplicate the project the most and still get away with it. Half the time the benefits of my approach become apparent after some time with the project -- the other half I don't get enough time or get a manager who doesn't want to understand where the productivity comes from.
peltoche 4y ago
Amen!
sdeframond 4y ago
As stated in the main schema in TFA: > Understand all of this, but use only what you need.
Akronymus 4y ago
As a junior who previously got thrown into the deep end on one project, where I have been essentially useless for way too long, but now am having actual guidance, and do one part at a time: I can only second that. Also: train your juniors, please. Getting thrown into the deep end REALLY hurts the speed of learning.
- Bjartr 4y ago
  What would you say good training for juniors should look like.
  - Akronymus 4y ago
    A learning project with lots of fast iterations where concepts get added over time. With feedback on each iteration from experienced devs where you are able to discuss why you chose x and what the tradeoffs are. At least in my case.
  - twawaaay 4y ago
    Juniors should not be learning the same things as senior developers. Imagining juniors as "mini-seniors" is IMO wrong. There needs to be a progression and you go from focus on low level stuff to focus on high level stuff. For any single thing, at least at the beginning of the career, you first start with copying, then you imitate, then you get proficient, then you hopefully go to understand it on a deep level -- mastery. Junior devs -- learn to use the tools. The focus of juniors should be on getting productive within the team and this means being able to do a significant volume of tasks that require least high level knowledge -- repetitive/routine tasks, low level tasks, localised changes. As far as the high level concepts, juniors are not expected to contribute or even understand them -- they are expected to be able to work within the the project structure. It is the tech leadership job to make sure that juniors can be productive even without understanding high level concepts, strategy, etc. Senior devs -- are expected to know the tools, learn the high level design concepts. They are also expected to have enough experience to be able to tell right from wrong. The focus of senior developers is to understand and be able to productively use high level development concepts. This means ability to design single applications, modules, interfaces, etc. Work productively with stakeholders. Work productively with juniors. Etc. Seniors is when you should start understanding programming patterns, paradigms, learn when to use them, etc. Seniors are not expected to be able to solve all problems and still require some supervision. Seniors also are not expected to be able to form or understand strategic concepts. Tech leader / principal developer -- are expected to know the tools, know high level development concepts AND also be strategic about it. Tech leader, however intelligent he/she is, is also expected to have immense experience at various types of projects so that he can immediately tell right from wrong and use his experience to put forward solutions that worked in the past and critique solutions that are known not to work. Tech leader is the person that needs to be able to understand and debug entirety of technical situation, form the vision of where he/she wants to be in future and put together coherent strategy. For example, tech leader is the one responsible for understanding blockers for individual contributor productivity and find strategy to improve and resolve these issues. Tech leader IMO should also be a person that is able to solve ANY problem, technical or otherwise.
skrtskrt 4y ago
Imo when it’s done well it doesn’t look like complexity at all and makes it simpler, not more complicated, even if there are more “layers”
- twawaaay 4y ago
  In my experience, when people look for a way to include something in the project it almost always results in more complexity. A question like "how do I put it all together" signals focus on tools rather than focus on the product. When developers learn new things they frequently look for opportunity to use them. This preoccupation with the tool they just learned usually happens at the cost of the product. They are looking for a way to add things to the project rather than look for ways to remove unnecessary things. The right state of mind for architect/designer is to seek learning/understanding paradigms, tools, technologies, etc. to have a library of solutions for when they are needed and be able to recognise when it is the right time to do it, not to try to find a way to use something they just learned.
hkon 4y ago
These are established and well known patterns. Better other people get to learn them sooner. The seasoned developers have probably experienced the problem they solve and the juniors might be saved from doing the same mistakes as others have before them. The argument that juniors will have a hard time understanding it can be said about anything you don't like / don't want. And then you can begin to lay it on thick. It's a convenient scape goat for sure.

thdespou 4y ago

This is probably a syndrome of overhyped lead developers trying to "engineer" a solution without consulting with the team beforehand. They read a bunch of articles, decide that it's the "best" solution and blend everything together in a soup of tools that don't make sense. I've seen that happening many times with bad results every time.

twawaaay 4y ago
Yeah... for some reason developers think that the higher position/salary requires them to put forward more complicated solution. Nothing further from the truth. My goal in life is to learn so that I can engineer systems and write code that is as simple as possible. It takes a bit of courage to put forward code that looks like everybody could write it -- which is exactly the point of getting more mature in software development. One problem I always had is that managers seem to reward people for how complicated projects they are working on rather than reward for putting in effort into making things simple. This makes a bit of conflict of interest but I personally resolved to do what is right and feel good with myself rather than to play the silly game of who can overcomplicate the project the most and still get away with it. Half the time the benefits of my approach become apparent after some time with the project -- the other half I don't get enough time or get a manager who doesn't want to understand where the productivity comes from.

peltoche 4y ago

Amen!

sdeframond 4y ago

As stated in the main schema in TFA: > Understand all of this, but use only what you need.

Akronymus 4y ago

As a junior who previously got thrown into the deep end on one project, where I have been essentially useless for way too long, but now am having actual guidance, and do one part at a time: I can only second that. Also: train your juniors, please. Getting thrown into the deep end REALLY hurts the speed of learning.

Bjartr 4y ago
What would you say good training for juniors should look like.
- Akronymus 4y ago
  A learning project with lots of fast iterations where concepts get added over time. With feedback on each iteration from experienced devs where you are able to discuss why you chose x and what the tradeoffs are. At least in my case.
- twawaaay 4y ago
  Juniors should not be learning the same things as senior developers. Imagining juniors as "mini-seniors" is IMO wrong. There needs to be a progression and you go from focus on low level stuff to focus on high level stuff. For any single thing, at least at the beginning of the career, you first start with copying, then you imitate, then you get proficient, then you hopefully go to understand it on a deep level -- mastery. Junior devs -- learn to use the tools. The focus of juniors should be on getting productive within the team and this means being able to do a significant volume of tasks that require least high level knowledge -- repetitive/routine tasks, low level tasks, localised changes. As far as the high level concepts, juniors are not expected to contribute or even understand them -- they are expected to be able to work within the the project structure. It is the tech leadership job to make sure that juniors can be productive even without understanding high level concepts, strategy, etc. Senior devs -- are expected to know the tools, learn the high level design concepts. They are also expected to have enough experience to be able to tell right from wrong. The focus of senior developers is to understand and be able to productively use high level development concepts. This means ability to design single applications, modules, interfaces, etc. Work productively with stakeholders. Work productively with juniors. Etc. Seniors is when you should start understanding programming patterns, paradigms, learn when to use them, etc. Seniors are not expected to be able to solve all problems and still require some supervision. Seniors also are not expected to be able to form or understand strategic concepts. Tech leader / principal developer -- are expected to know the tools, know high level development concepts AND also be strategic about it. Tech leader, however intelligent he/she is, is also expected to have immense experience at various types of projects so that he can immediately tell right from wrong and use his experience to put forward solutions that worked in the past and critique solutions that are known not to work. Tech leader is the person that needs to be able to understand and debug entirety of technical situation, form the vision of where he/she wants to be in future and put together coherent strategy. For example, tech leader is the one responsible for understanding blockers for individual contributor productivity and find strategy to improve and resolve these issues. Tech leader IMO should also be a person that is able to solve ANY problem, technical or otherwise.

skrtskrt 4y ago

Imo when it’s done well it doesn’t look like complexity at all and makes it simpler, not more complicated, even if there are more “layers”

twawaaay 4y ago
In my experience, when people look for a way to include something in the project it almost always results in more complexity. A question like "how do I put it all together" signals focus on tools rather than focus on the product. When developers learn new things they frequently look for opportunity to use them. This preoccupation with the tool they just learned usually happens at the cost of the product. They are looking for a way to add things to the project rather than look for ways to remove unnecessary things. The right state of mind for architect/designer is to seek learning/understanding paradigms, tools, technologies, etc. to have a library of solutions for when they are needed and be able to recognise when it is the right time to do it, not to try to find a way to use something they just learned.

hkon 4y ago

These are established and well known patterns. Better other people get to learn them sooner. The seasoned developers have probably experienced the problem they solve and the juniors might be saved from doing the same mistakes as others have before them. The argument that juniors will have a hard time understanding it can be said about anything you don't like / don't want. And then you can begin to lay it on thick. It's a convenient scape goat for sure.