loading...

re: How to build a Pragmalith VIEW POST

TOP OF THREAD FULL DISCUSSION
re: "I don't trust myself to have the discipline to avoid shortcuts in the code. " I would suggest to build it. That's great to have a REST API, but i...
 

Everything should be contextual to the team. In our case REST made much more sense than any other approach. For a different team and a different app it could have been different. Another thing to consider once again is the cost of learning something else — it really has to bring huge benefits to be justified. All I'm saying is that you need to pick the approach that takes care of most of your problems rather than relying on devs to maintain a high level of discipline. Another example of that can be seen in the use of static types.

I've also seen many different approaches to software dev come and go but one of the core principles has always been to find systematic ways to reduce risks. That's why we do code reviews, automate tests and deployments, have immutable infrastructures. Everyone is, of course, doing their best, but it's so much better to know that safeguards are built within the way you work. "Don't trust yourself" is not meant to say you're bad at your job, but rather that bad days can happen.

Hope that makes more sense.

 

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.

I agree. At the end it's more the way you say it which bothered me, more than what you meant by it.

Code of Conduct Report abuse