itsArtur's comments

im curious - what are some other examples?

I think it's getting better - a number of countries worldwide (such as Portugal or UAE) are making it easier and easier for people to work remotely as "contractors". While not perfect, it's definitely a good solution for highly skilled workers who have a strong negotiating position and can ask for all the benefits their country's labour law would otherwise assure.

I have used Retool to create a (well-received) PoC of an internal-facing admin app. I was pretty impressed, even though it had some rough edges.

Setting up UIs was relatively painless thanks to many out-of-the-box integrations, and it was surprisingly easy to implement auth/error handling/component dependencies.

The thing I liked the most is that it's not really a "no code" - you need to be technical to build good apps in this tool. However, that's where the power comes from - it simplifies the mundane development tasks and lets you focus on something more high level.

I wish the team would make it easier to consume your own, custom API however.

Do you mind sharing the good source?

I like the C4 model because it forces me to think about the right level of abstraction for the diagram's audience. It also has very few core building blocks and thus is very easy to learn. I just wish the tooling around it was better :)

> A lot of people who I knew as sympathetic and calm before they took management roles turned into something I could code in one minute: namely a program that asks "how much is this going to take?" and if your answer is above N hours/days then they say "no, we're not doing it". And that's not because they are stupid or suddenly non-sympathetic. It's because their bosses optimize for those metrics and measure them (and their salary, and their bonuses, and even their vacation days) by the same metrics.

I had this exact same thought recently when reflecting on my behavior in my new role as a "technical product owner". All of it was reflexive, as if I suddenly forgot all of the software engineering knowledge I accumulated over the years and became a deadline-driven cog.

I don't have a solution yet; I think it comes down to that I don't yet speak the same language that people I report to do, and thus I feel like I can't defend my position well enough. It comes with experience, I guess!

Wouldn't that deposit requirement cause issues for high volume/low margin sellers?

> Software architecture probably matters more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.

That's fair, but shouldn't we strive to make the best possible guesses in the absence of said theory and science?

Use Revolut

What's the practical implication of this fact?

> I can imagine that the lack of such feedback not only results in slower learning. It might mean the non-apprentice programmer is unable to ever acquire an intuition for design no matter how many years of experience.

Yes! This is also worsened by the fact that changing jobs frequently is so common. This makes me appreciate my first job, where good design was a priority, so much more.

I always use IntelliJ for code reviews, works great.

Is it a satire?

I am not parent comment's author, but I use TS on the backend and I did look into ReasonML. I love most of Reason's syntax and FP in general, but unfortunately, reason/bucklescript ecosystem just isn't mature enough for a serious project. I'd recommend against using it unless you are in some megacorp and you can afford to build general-purpose tooling.

I am not a native english speaker and it was really difficult for me to read this essay and understand its purpose. Is this writing style considered "good"?

I don't think there was one specific thing that helped me keep these sessions going, it was a long a pretty long and tedious process, to be frank.

I had to convince both sides: 1. the management so that they would give us explicit permission to take time from our "actual work" time 2. the devs to actually start and keep it going

management caved in after... - I researched our competitors and their tech, highlighted features which would be very hard/impossible to implement given our architecture and what we needed to learn - dozens of comments about what we lose implementing feature Y in the "old" and "known" way vs using tech/service X - made comparisons to different professions which always have to stay on top of their game to win

all while repeating the message that we cannot have a world-class product without a world-class tech team. I think framing this as a "loss" instead of "gain" helped a ton.

With management buy-in, we were creating a "learning" card for everyone in the tech team each sprint. These cards were "committed" so there was no getting around of finishing them.

The dev team needed some motivation as well. Coding features as quickly as possible has obvious and visible advantage - you get praised, you might get a bonus, you might be promoted. Learning on the other hand.. less so.

To keep a long story short, I convinced them that the more they know the better their market value is by showing various stats. After the initial nudge, it was just intellectual curiosity that kept the meetings going.

Format wasn't anything special: - pick a book/article/system by vote - one person spends a couple of hours going through the chosen 'thing' - prepares a list of items to talk about - people vote about what should we talk about (before the meeting) - we have a presentation/discussion. each meeting ends with - list of practises/ideas we would like to implement. the list is committed to our documentation repository and followed up on - list of things we would like to learn in the future

I thought about the same thing! I think having your code reviewed is one of the fastest ways to improve and at the same time, it's currently very hard to have it done.

I really dislike CodeReview SE for many reasons though, I don't think this Q&A format is suitable for doing CRs