Zvez

I didn't get this article. It seems like it contains two things: 1. It was already invented before 2. All the wrong reasons why people decide to use microservices.

But author clearly avoided the real reasons why you actually need to split stuff into separate services: 1. Some processes shouldn't be mixed in the same runtime. Simple example batch/streaming vs 'realtime'. Or important and not important. 2. Some things need different stack, runtimes, frameworks. And is much easier to separate them instead of trying to make them coexist.

And regarding 'it was already in Simpsons' argument, I don't think it should even be considered as argument. If you are old enough to remember EJB, you don't need to be explained why it was a bad idea from the start. Why services built on EJB were never scalable or maintainable. So even if EJB claimed to cover the same features as microservices right now, I'm pretty sure EJB won't be a framework of choice for anybody now.

Obviously considering microservices as the only _right_ solution is stupid. But same goes for pretty much any technology out there.

> a sane thing to do

imaging your application contains of two pieces - somewhat simple crud, that requires to respond _fast_ and huge batch processing infrastructure, that needs to work as efficient as possible, but doesn't care about single element processing time. And suddenly 'the sane thing to do' is not the best thing anymore. You need different technologies, different runtime settings and sometimes different runtimes. But most importantly they don't need constraints imposed by unrelated (other) part of the system.

I've been a professional developer for more than 10 years and I have similar observation. Most of developers don't use touch typing. And it doesn't seem to affect their efficiency at all. Developers usually don't need to produce large amount of code (unless you are Go developer ;) ). They use auto-completion, copy-paste and usually need to do a short edits and not 20 lines of non-stop typing. So even though I use touch typing myself, I've never seen this as a big advantage making me somehow better than others. I see benefits only when I am in a long chat discussions.

>Most Americans under 40 would have learned touch typing in grade school

That's interesting. Do they really use it though? What I can see from other part of the world that even developers don't use it.

https://github.com/jankrepl/mltype is something like this. It is tuned for programmers though. And the quality of generated text might vary a lot. But it gives reasonable char sequences.

not exactly. Just like with the regular code, most of the stuff done on database are pretty trivial and not resource heavy. And the things that are really perfomance-critical are usually crafted very differently even in SQL

>where the system will sometimes re-suspend itself a moment after opening the lid. a minor annoyance that I haven't taken the time to debug yet

heh, I have a similar issue on my T470 in xfce. And in my case it can sometimes even hang in this state: you see your desktop, but can't interact with it. So you have to go the terminal and kill screensaver service.

The small issues like these are the reason why I still prefer to use macbook for work: its not perfect and might be too opinionated, but at least it is predictable.

I don't get this argument. You can burn your house, but it doesn't mean you should live in a hotel.

The difference is that while I can do it by mistake, Amazon can do it intentionally.

I wouldn't call it bad writing. It is different from what I used to. It is non-linear, which is actually quite common (eg see Hyperion) and I would say not-character-focused. It is more about a concept itself. And even though latter I don't like much, the core idea of the book is very interesting.

For me it was harder to read, but still very enjoyable experience.

>And it ends abruptly before resolving anything hmmm, I wonder what kind of books you usually read. Because this is very common approach, when authors don't do full LoTR ending, but end story at the point when reaching it would be rewarding, but won't everything to the last bit, so readers can still think about for a while.

This is so wrong. 'they don't want to learn, lets force them'. Understanding that some people don't need it might be waaaay too hard. Majority of people don't need 'more powerful tool', which needs to be learned for more time than they actually need to use it.

it probably means to run actual instance of neovim and use it as a backend for current editor's content.

Good stuff. But I still probably wouldn't use it. Because my cli usage can be roughly divided into two categories:

1. Commands I use often (daily). These I usually know and they are much faster to type than to explain what I want to do.

2. Commands I need to google/man to do something specific I don't usually do. And these I usually want at least understand before running them. For example some git manipulations.

So AI tool can be helpful for (2) but most probably I will still go to google to read more about what does the command do.

I wonder what you usually write in these notes? I can understand writers/bloggers who can just use it as their motivation tool to do their job/hobby. But for the rest of us, what would you write there every day?

> I could totally see specific people getting hit at the right angle and be affected enough to warrant consideration

The question is, will they be affected by word itself or the composition of words? Because I can probably make an offensive sentence using most of the words in this list (except tarball, I'm not that creative). But I can also do the same avoiding words from the list and still hurt specific people. So having this list doesn't solve the problem, but it can be used to harm people. You don't like some argument, lets check if we can find a harmful word in it and use that!

Yep, this should go to commit metadata or at the very least as an additional part of commit message with proper marking.

Those 15 saved minutes you will have to spend to validate that generated message actually makes sense. And if you are not careful, you will have to spend much more time 'rewriting history' later.

Also if an engineer has troubles describe change than maybe you don't want that change to end up in you repo.

This. I've seen to many times how some people ask direct question which doesn't have simple answer. So they instead get answer with some context, questions and conditional statements.

It happens often when question goes through 'occupation boundaries'. Eg you are manager (judging by 'my experience is with SWEs') and you ask 'simple' direct question from swe "can you implement this feature". And instead you get wall of text. Which might be frustrating, but is it SWE to blame?

>Ugly code that works pays bills. Beautiful code that doesn't work is, in a very literal sense, worthless

what about good code that work? All places where I see your argument prevail, ended up to be not just 'ugly code', but unmaintainable code. And systems that cannot evolve at all.

Personally I don't call coding an art, but I've seen countless times how people people choose bad solution even though better one costs exactly the same, and in a long run - actually cheaper. And they _always_ use this argument - 'code is just a tool, if it solves the problem, it is good'. And then they either leave or have to spend weekends to write even more dirty code just to solve problem they wouldn't have in the first place if they spent a little bit more time thinking about the code.

>There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually engineering

In my experience there is almost no correlation between complexity of the project and time needed to do 'non-technical' work. Quite contrary, the most complex things I did as a dev required me to do a lot of coding - to prototype, to experiment, to load testing and so on.

And at the same time the easiest project in the larger corporations required me to write down design docs for trivial stuff and spent months in meetings to 'align' with people, who don't have time to even read your design doc, but want you to have bi-weekly meeting about it.

So no, I don't buy this excuse anymore. Unless you are building space ship or do very unique work, there shouldn't be any need to spend 80% of your time in non-strictly-technical work.

actually this is more than normal in all 3rd world countries. Starting from 6-7 years most kids walk to/from school on their own.

I feel uncomfortable just by looking at its keyboard

nope this is variation of 'don't write obvious comments to your code'. Useful comments can include the 'whys', links to design docs/decisions, references to other part of source code. Here we see the case of commenting everything for the sake of commenting. Without adding any additional knowledge/insights.

in this particular example at least for me it is easier to read the original code. Even though I don't even know the language they use. And I'm pretty sure this is the case for the most developers with non-zero experience.

Yep. Not only it generates useless comments, for me it is actually easy to read the code itself, than the generated comments in this case. I don't know neither language nor framework they use, still it is completely readable.

Looks like fake to me. No sources. The title says 'ordered', by article itself about 'sold out'. The sold out part is actually true and was reported by multiple sources.

In my 15 years of experience the true happiness comes from the ability to choose what you want to do and avoid things you don't. So if you in the place there you can specialize early in your carrier and know what you want to do - go for it.

But in my case I never had this chance in my first ~5-10 years in the IT. I lived in 3rd world country with like 3 IT company in the town. So I had to be generalist.

Right now while I'm still capable of doing more or less everything, I have my 'standards' of jobs I'm willing to do. For example I don't do frontend, not because I can't, but because I prefer to not do it. So basically right now I have a set of things I enjoy and I try to make sure I work on them. Probably I would be in a much better position if I could specialize in more complex fields (in terms of career opportunities), but at least I have enough experience to have some options I like.

Any suggestions of good 'prerequisite' courses on data structures for this?

I can also argue that is is almost impossible to show code to you for very simple reason: showing couple of files won't make any difference for you anyway and you can't just transfer your codebase to a person. The only thing you can do is to sit candidate to a laptop with the codebase for couple of hours, but I doubt anyone will go that far.

I achieved this state of 'you can choose whatever you want to do here, you are too useful to loose' on my previous job and it was pretty great. The main problem with this is you have to invest couple of years to get proper reputation. But you need to be mindful about what you actually get for your efforts. I've started working at [faang] a year ago and now I'm pretty sure I've wasted this year. While I got my share of good reputation, the team I'm working in is basically an island. There is no visibility to other teams, so I can't convert my local reputation into ticket to choose projects I like.

I wonder is it really necessary to explicitly ban every sort of discrimination? Shouldn't it be simple 'discrimination is not allowed'? Otherwise we will be listing every type of discrimination and revisiting this list every now and then. And it leads to questions like 'is it acceptable to discriminate by boldness if it is not in the list?'

While I agree that such not-so-well-known discriminations should be publically discussed, I feel like 'banning' them one by one is the wrong direction to take.