2,093 karma · joined April 7, 2017
And if you don't want to play along with the 'winner-takes-all' dynamic, then by consequence you'll lose anyway.
Politics as the heart of deliberative democracy seems already like a long lost ideal, or maybe that is too romantic a thought and it never really was like this to begin with? Maybe I am just getting old.
As I web developer I see so many CVEs in mature stacks, and every so often they really do apply to our work. It is hard to avoid updating, unless you kind of pretend those vulnerabilities don't exist or apply (honestly, the vast majority of devs and small orgs do just that). Even monitoring and deciding what vulnerability applies is a recurrent 'waste' of time, sometimes you might as well just do regular updates instead.
One issue I often see is that if you do your job well, any time sunk into security can by definition be seen as wasted. Until that rare moment comes when it is not so, and then it suddenly transforms from wasted time into a business critical or even business ending death crunch.
1. Process. As a guiding principle, it is easier to make frequent small steps rather than one big step. There are many reasons for this, and the benefit of frequent small chunks of work apply beyond updates. 2. Security. Frequent updates can improve security posture, for different reasons: you apply undisclosed security fixes without knowing it (not everything is a CVE), prevent unnoticed vulnerabilities (this can be fixed by automated monitoring) and when there is a time-critical upgrade, the work is faster and less risky (see previous reason).
Pinning and updating reactively would be fine and sometimes is, however: there will be security issues, you will have to update. Given that the task is hard to avoid, for any product that is actively maintained and developed I think the better choice is to do it regular updates regardless of security issues. Maybe with good monitoring and for products that are really not developed any further just reacting to security issues is the better choice - its often also a pain though.
But maybe if you have a codebase with a lot of magic of certain libraries, you experience is different. I also don't really depend on the typing treat it the same as C# or Java.
First of all, you can't really model exactly what chefs do algorithmically. Or you can, maybe, but you shouldn't do that in a recipe. Unless you are building an autonomous robot-chef arm. I've seen these in China, they only cook very simple dishes.
What developers tend to forget, the recipe is a tool, and it helps chefs put together a dish. A mere combination of ingredients and maybe cooking techniques is usually sufficient for that. It is NOT an algorithm.
That's why I liked the 3 column layout linked somewhere else in this topic better than the cooking for engineers forget: it has less information which makes the things that matter stand out more.
If anything, these formats capture way too much information. For example, you can't really measure cooking times reliably unless you do sous-vide, if you want to be precise, measure temperature.
We're trending very far to the right as a whole, with the edges getting bigger and more extreme by the year.
Trump's success in only partly due to his inheritance though. I'd liked it more to a charismatic religious and authoritarian leader.
Even though the children's books lack nuance. There are no problems with pollution and climate change in Scarry's world. There are no jobs that people do not like to do. Malice and greed is very limited, sickness never really frightening.
But still, the overall vision of goodness from the perspective of a child's innocence is valid and accurate. Adults at some point either just give up or mechanically hold on to dystopic beliefs because they feel it is part of their identity.
But it might just be a lack of imagination. Which is why hope and change always come from new generations, and the best elders can do is gently support them and step out of their way.
Another one we really like is the Gruffalo, by Julia Donaldson. A classic, which is also really fun to read as an adult. I wish I know of more of these kinds of high quality children books.
Roald Dahl is another such writer who just doesn't care and writes what is fun for kids to read. I loved his books when I grew up. But its for a different age.
And, it works the same with us 'normal' people, even though the results are less spectacular. Want to have a good idea? You need to feed your brain everything you can and obsess over it, then let it stew for a bit. Again, and again. Only then do you stand a chance for a really good idea to just pop out.
Joking aside, you really do need to solve the problems jsx solves, but also webpack, next.js, react-router and depending on your application, something like mantine or tailwind. These are the minimum I think.
If you have a smallish project you can get by hand-rolling your own solutions, but it doesn't make the problems themselves go away.
In fact, it is exactly the claim in this thread that there are a lot of beaten paths in backend languages with relative stability over time, whereas in frontend it is 1) not clear what the beaten path is (there isn't one) and 2) when there appears to be favored solution, it often changes radically or disappears after just a couple of years.
For example, create-react-app used to be the default way to start a react app, it is now deprecated. But for python, Django has been a stable beaten path for many, many years. Same for Rails. C# also tends to change every couple of years, but there is always just one single Microsoft recommended way to do things.
Sure there are many experimental libraries and contenders in these languages as well, but there isn't really anything with the same maturity and stability in frontend.
It is unavoidable to have a truly gigantic amount of (transitive) dependencies, and its rare you go a month of updates without it breaking your app.
It is true that for backend it is more or less the same, however it is a matter of degree. If frontend is all you do, it may be managable, but for full-stack devs who also need to manage infra it can sometimes be overwhelming.
I know a lot of developers that were really happy in that older Microsoft ecosystem, it was a semi permeable walled garden where you could walk 'the Microsoft way' and everything was kind of laid out before you, neat and cosy. At the dev conferences when javascript started to become unavoidable, there was still a period where they kind of pretended Microsoft invented the web and gave it a nice but small spot alongside all the other, more important technology with which Real Developers make Real Software.
You could have discussions on architecture, but nothing fundamental really, and you'd always follow the prescribed pathways that Microsoft thought out for you. These changed every couple of years, which gave everybody new goals, new certifications to reach, new rewrites to accomplish and get paid for. Anyone that was moderately skilled was quite productive, and it was very easy to get into.
When the web got more complicated than html + jquery in server side generated templates, these developers often had a very bad time and fully retreated into their 'backend' role. The most recent anti javascript stronghold is Blazor, not sure if that is still a viable way to avoid modern frontend tooling.
I never really understood why Microsoft abandoned desktop gui apps like they did and left their walled garden unattended. It was one of their strong points, even though I disliked it a lot.
Productivity is not progress, for sure. You can be very productive building the wrong thing. I've been there, wasting a year on some crap that was canned. But you need to be able to deliver and not actively frustrate your devs that want to get shit done. Otherwise the 'adapted to the market' is just a scam at best.
btw, not every dev is the same. Some actually do like being in the office, even putting on music and have lots of small talk. That's also fine, if it works for them. And I also see benefit of going to the office myself (once a week or so).
I'm pointing out the pattern of sales & management incompetently projecting their own needs and biases onto the whole company and treating devs as grunt workers, forcing them to comply with their rules and fulfill their needs regardless of how it impacts their ability to concentrate and deliver. Software development is not grunt work.
I see fulltime RTO orders as a reflection of this. Smarter management will understand what devs actually need and take that seriously. Usually this kind of management has a technical background. Office can be a part of that, sure, but wfh invariably is too, I'm convinced.
I've worked for dozens and dozens of managers in my career. Some will go out of their way to buy you the best laptop, even make you coffee and give up the best seat in the office just so that you can work in peace. Because they know that such investments in their staff will pay off. Then, others will loudly interrupt you, deny any small request out of petty resentment, and blame any and all problems on your laziness - that is if they actually show up to notice there is a problem.
Occams razor requires you to drop assumptions that aren't required to explain a thing. A conspiracy involves a lot of extra stuff, furthermore it is often hard to find evidence for - usually because they just don't exist. There are so many problems with them, it should really be a matter of last resort.
Conspiracies do exist of course, but I feel you should only use time to explain the world if you have sound evidence, and still be open to falsification.
I've worked in places where sales people were seated next to programmers, and the sales people were shouting through their phones continuously. The programmers complained endlessly about all the noise - without effect. First lockdown we had showed an increase of at least 300% productivity - hard and reliable numbers because all output was tracked voluntarily by the team (management never asked for this). Number of builds, commits, releases...everything was way up. It was quite shocking.
As soon as lockdowns were lifted managers began talking about being in the office fulltime, because it was so good to talk to each other and align your work. I remember working in a team that did 1 day a week at the office, that day we couldn't get anything done because everybody was just chit chatting all the time. Even if you wanted to - it was just impossible to focus.
Our security officer (CISO) remarked how the lockdown enabled him to think seriously about a security issue for the first time in almost two years. Isn't that tragic?
Companies are as rational as consumer behavior. You can't make this stuff up. Never attribute to malice that which is adequately explained by stupidity.
There's a big difference between 'you can look at the source but not use this product in the way it is intended if you make money by doing so' (production use), and 'you can use the source in any way you like, also for production, but not to compete with us'. I've always understood 'source-available' to mean the former because it used to be like that, and the latter to be a slightly restrictive version of open source. Historically, the latter variant also emerged out of competition with the big clouds (mostly AWS), from projects that used to be truly open source, whereas a lot of what I think are source-available licenses come from vendors that were fully closed before or would be if there was no demand to see the source (for example, for security purposes).
Daily: should average at 10 min, 15 min is really the maximum. Including prep. So 5-15 min. No status updates! The daily is about getting people unstuck with their current tasks and quickly aligning on what to do next. If it is not useful for the team, the implementation is wrong. Doesn't mean it always has to be useful and interesting to you, there's a difference. Management stays out of the daily.
Sprint planning: the sprints are the compromise to management so we can have some sense of progress, so this is of course the one meeting that is useless to the team getting work done and can hamper productivity. Just make it quick.
Retro: you should do a retro about if you think the retro is useful and why/why not. If the team doesn't think it is, either change it until it works or make this the very last one. Management stays out of the retro. ("But are you then not doing scrum anymore?" "So what, save the pedantry for writing out the functional and technical requirements please")
Thing is, you do need to understand what you are working on, and it needs to be more or less the same as what your team members think they are working on. If you are 100% efficient at building the wrong thing, your 0% overhead amounts to exactly nothing, and the 80% efficient scrum team is infinitely more efficient. Though these extreme cases are usually a problem from higher up, without any way to align your work you will usually not be efficient. And if you are, then good for you, don't follow scrum like its some cult. But most teams need a little coordination.
Basically if anybody feels a meeting (or anything, really) is a waste of time, there is a problem that needs addressing. And the problem is not the feeling, but what is causing that sense of waste. Take it seriously, it is almost always signaling a flaw in the process. Learn how to talk about this in the retro and get to the bottom of it.
The retro is about debugging anything that isn't working optimal in the team. If you cannot find any bugs and fix them, then you are either perfect or just not good at debugging, and I know which one to bet one to be the most likely. One sure sign a team isn't very capable is when there is a lot of blaming involved. Usually external factors or tools get the blame, but in very dysfunctional teams people blame each other.
If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.
But reading the article made something click: it is not about the specific process, the (lack of) autonomy is what really matters. I guess I got lucky to work a lot in teams where we largely controlled our own process, so even if we used bits and pieces of scrum, kanban or other methodologies, it was always of our collective choosing and when it didn't work, we changed it.
I did like to have rules, principles and process. A simple playbook for a daily meeting that made us not forget important things and sped up the meeting. Making things in small increments meant that I didn't have to review thousands of lines of code. Having a visual overview of work neatly spelled out means I don't have to re-think every time I pick up a new item to work on. This also prevents useless work because one of your teammates decides to work on the same thing as you without telling it. All these things make me happier and more productive working together on some big thing.
The key is that the team should be in control of the process, not some manager who isn't part of the team and affected by the process. You need to have a stake in it. The only other factor that undermines this is 'process for the sake of process'. Every part of the process needs to earn the inevitable cost its implementation is bringing. Some people seem to be happy paying the pricing without getting the value.
Likewise, the risk only applies to the premium feature set. If those are that crucial to your operation, you would assess that risk more or less in the same way that you assess a proprietary product - because that is what it is.
For example, if all the security features are essential to your work and you pay for the ultimate version, then Gitlab is more or less a closed source product for you. However, if you are a big company and use self-hosted free version of gitlab to have a cheap inner source hosting for all employees, then it is exactly as if you use an open source product.
There are more nuances of course in a real assessment, but basically the open part is open source and the closed part is proprietary. Very simple.
Furthermore, you can't even talk about the open core as a part of the closed source product, because the open core application is invariably a whole in and of itself. You could theoretically fork it, improve on it and it could have a life on its own as a 'fully' open source product. You can even make it incompatible with the closed version.
So I think it is core to the way Microsoft expands and holds market share. And that market has changed to not only want windows only tools, so they change with it. Microsoft culture has always been kind of pragmatic. They were a walled garden for developers when they could get away with it (and still are for some), but now they have opened up a bit out of need.
Because yes, in theory a customer can 'just' switch to another product. In reality though, there are various reasons why it isn't so easy. Customers get invested with their time, build skills, have projects, or just plain inertia. It takes some mental load to compare alternative products and make the switch. People are busy.
We don't think of bait-and-switch business models as scams, but once you see them as basically scams-light it becomes clear it is at least an open-question if their existence furthers the glory of the free market, or hinders it. We don't have a problem seeing scams or criminality as basically obstructing a free-market.
Eventually Canva will perish if they make the deal bad enough, unless they somehow achieve a monopoly or sales stranglehold (my term), but not before they squeeze a good few bucks out of frustrated users. If they are successful enough at it, it hollows out the market.
The initial investment to start a company, especially a tech company, isn't all that big anymore.