Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
I agree with you. Even if they do their best, developers make mistake. That's why we have many, many tools to prevent them. It makes sense, development is hard, because we have these huge codebases we need to put in our head and try to find reasonable solution.
However, if you "don't trust yourself to have the discipline to avoid shortcut in your code", do you really do your best? Making mistakes imply that you don't know the mistake you do; if you know it, then don't do it, or find a way not doing it. What I understand with your sentence is: I know I'm coding a shortcut, it's bad, but I don't have the discipline to bring a better solution. The mental process here seems wrong to me.
Don't get me wrong: I made shortcuts, and I will do, again. But I don't want to say that it's normal and I was right. Even if the context pressured me to do it. I should simply acknowledge my mistake, and try not doing it in the future. It shouldn't even less explain why I choose a technology instead of another.
On your choice for REST APIs, I think you should choose the good tool to solve your specific problem, not choosing the technology because everybody knows it. We are developers, we can learn. If we can't, we will have quite some problems soon, when we'll need to adapt to some new technology / language / whatever.
I don't say that your choice of REST APIs don't solve your problem. I don't know, maybe. What I say is, for me, your reasoning is dangerous.
As an example, I had a technical leader once who said that modern JS frameworks were too complicated, and we should use what everybody know: jQuery.
It was a mess. The Frontend was way too complex for the poor jQuery. The developers in love with it left, and they couldn't find anybody who wanted to code jQuery. A total disaster.
I see the point you're making and I don't think it goes against what I've said. I've never said that you should only pick things you're familiar with: case in point with using React/React Native at the time. This decision was based on what it could help us do rather than what we're familiar with. But it's surely dangerous to try to innovate in all aspects of your codebase and infrastructure. Don't focus on the choice of REST, but rather look at all the decisions we had to make at the time.
However, if you "don't trust yourself to have the discipline to avoid shortcuts in your code", do you really do your best?
That's risk assessment 101. In every org I've been (ranging from small startup to post-IPO) the consensus is that you should provide safeguards, no matter how experienced people are, and especially as you grow. I feel like you're taking my point as an attack on competencies — it is not. People get tired, bored, or have to work under pressure at times. Good risk management takes that into account. In our case, we're currently a team of 2 having to juggle multiple hats (devs, marketing, ops...) and the less I have to think about how to build things, the better. Once again it's contextual and YMMV.
TL;DR; I don't think we're in so much disagreement.
Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
I agree with you. Even if they do their best, developers make mistake. That's why we have many, many tools to prevent them. It makes sense, development is hard, because we have these huge codebases we need to put in our head and try to find reasonable solution.
However, if you "don't trust yourself to have the discipline to avoid shortcut in your code", do you really do your best? Making mistakes imply that you don't know the mistake you do; if you know it, then don't do it, or find a way not doing it. What I understand with your sentence is: I know I'm coding a shortcut, it's bad, but I don't have the discipline to bring a better solution. The mental process here seems wrong to me.
Don't get me wrong: I made shortcuts, and I will do, again. But I don't want to say that it's normal and I was right. Even if the context pressured me to do it. I should simply acknowledge my mistake, and try not doing it in the future. It shouldn't even less explain why I choose a technology instead of another.
On your choice for REST APIs, I think you should choose the good tool to solve your specific problem, not choosing the technology because everybody knows it. We are developers, we can learn. If we can't, we will have quite some problems soon, when we'll need to adapt to some new technology / language / whatever.
I don't say that your choice of REST APIs don't solve your problem. I don't know, maybe. What I say is, for me, your reasoning is dangerous.
As an example, I had a technical leader once who said that modern JS frameworks were too complicated, and we should use what everybody know: jQuery.
It was a mess. The Frontend was way too complex for the poor jQuery. The developers in love with it left, and they couldn't find anybody who wanted to code jQuery. A total disaster.
I see the point you're making and I don't think it goes against what I've said. I've never said that you should only pick things you're familiar with: case in point with using React/React Native at the time. This decision was based on what it could help us do rather than what we're familiar with. But it's surely dangerous to try to innovate in all aspects of your codebase and infrastructure. Don't focus on the choice of REST, but rather look at all the decisions we had to make at the time.
That's risk assessment 101. In every org I've been (ranging from small startup to post-IPO) the consensus is that you should provide safeguards, no matter how experienced people are, and especially as you grow. I feel like you're taking my point as an attack on competencies — it is not. People get tired, bored, or have to work under pressure at times. Good risk management takes that into account. In our case, we're currently a team of 2 having to juggle multiple hats (devs, marketing, ops...) and the less I have to think about how to build things, the better. Once again it's contextual and YMMV.
TL;DR; I don't think we're in so much disagreement.
I agree. At the end it's more the way you say it which bothered me, more than what you meant by it.