Agree with the headline but I think the takeaways are a little too cynical. You don't really have to take such a confrontational approach with future employers.
IMO the biggest takeaway I had after a layoff: Always try to navigate your career so that you are doing something valuable to the business. You can tell based on a lot of clues whether you're in a position that's valuable or if you're forgettable. Moving "toward the money" not only helps job security but it helps your compensation too.
Say for example your team has a stretch of a few months without any new high priority requirements or requests. A young developer might think, "Yay, finally we have enough time to do all that refactoring in the backlog." But in reality, that situation should make you very concerned.
Which of them -- the original (and still on TFA), "Once You're Laid Off, You'll Never Be the Same Again", or the current one here, "A layoff fundamentally changed how I perceive work"?
(And YTH did it change to something else??? Weird.)
I'm not sure if the legend is true or not. But this argument doesn't really disprove it. The devices don't need to send full audio recordings. They are powerful enough these days that they can do a cheap on-device audio analysis and tagging, and then upload the (very small) tags. It doesn't need to be Siri quality analysis because it doesn't matter if the analysis is incomplete or sometimes inaccurate. They would just be scanning for certain keywords.
As for whistleblowing... Is there really that much to whistleblow about it? We already know that ad-based companies like Google are collecting our data every chance they get, because they make billions of dollars from it. They're scraping our emails, studying our GPS location, paying attention to who we are in proximity with, etc. The level of surveillance is incredible and people don't really care. It wouldn't be headline news to find out that they are taking advantage of yet another side channel.
That’s not the only thing that maintaining consistent style involves. For example, we have an auto linter at my job, but there have been a few (bad) engineers whose code I can recognize even after it’s all auto-formatted.
Plus, when you’ve spent enough time with the code in varied environments, you start to internalize what it should look like. Seeing something that doesn’t match the style guide will stand out as looking funny.
I don’t think they were suggesting that you need to memorize every minute detail of your prettier config to be a good engineer. Rather, a good engineer has focused on writing clean-looking code so intensely for so long, to know it automatically.
Exactly, I’m all for readable code but this style guide stuff is cargo culting. The guides are the culmination of wisdom of past decades where IT became dominated by a few language stacks. Innovation happened elsewhere as computers got faster, bigger and use cases grew but did not transform. This changed and use cases and targeted platforms are different now calling for new stacks with new conventions. A typical developer is exposed to myriad languages and tools. Documenting small details in proper format never was enough but these days it has become ever more important to focus on communicating context and motivation.
That works for new code, but I'm much less keen when maintaining legacy code. Sure, you could reformat every file and then proceed to work on them, but then you've had a serious impact on the version history, worsening tools like git blame and often making it harder to understand how a particular piece of code evolved. It's even worse if one reformats and then makes a code change in the same commit...
fixing whitespace is something to do while thinking about the code. unless you can't do two things at once in which case it's a problem. either way, autoformatting doesn't magically make you engineer faster unless your company enforces a style in a really fascist and pedantic way
Autoformatting makes me faster because I don't have to think about it at all. All of the code in the codebase looks pretty similar and it opens up a sliver more mental RAM
If anything, each chunk of code having its own distinctive structure would make the code easier to visualize. If all the code looks the same then you have no landmarks. Do you not visualize code?
I do visualize it but the logic is the landmarks. It's like living on a grid system such as in Utah or New York but you still know where Times Square is and how Broadway connects everything
You cannot know the logic prior to reading and understanding the code unless you recognize the code immediately on sight. That is my point. If I see a nested ternary expression with beautiful indentation, I know I've scrolled too far when I'm looking for a certain method.
Method names are not logic. You really don't use distinctive method names or formatting to orient yourself and your colleagues? That sounds awful.
I misunderstood what you meant then. Obviously I use descriptive names and different styles of elements inherently have different shapes to them but I don't choose to add extra lines or change spacing just to make something look distinct. As I scroll through I see blocks, names, fors, lambdas, these form the shapes of different bits of code. The baseline formatting of each of these elements is uniform though
> More generally, I think WASM is starting to challenge the whole "there can only be DOM/CSS/JS" thing that has held web developers back for two decades.
No one was held back, people keep choosing the web because it's consistently better.
What I think is crazy is this drive to take something that is working great (the Web), and then jam in an approach that has already failed multiple times. We already tried several iterations of binary-heavy, non-transparent, non-searchable, non-web-native, second-ecosystem application platforms including Java Applets, Flash, Silverlight, etc. They had a chance and users rejected them.
If you think the web sucks, then by all means, I encourage you to make a compelling alternative. If it really is better then people will use it. But maybe don't try to spoil the working recipe of HTML/CSS/JS, especially if you don't fully understand the reasons why it keeps winning.
> No one was held back, people keep choosing the web because it's consistently better.
It's not consistently better. It's just marginally easier to develop simple things for.
> They had a chance and users rejected them.
Users rejected them because they were slow, bloated, and didn't play nice with a lot of things. Fast-forward to 2023, and users have embraced mobile apps (and not mobile web/PWA crap that we're told is about to get just as good as apps any time now).
> If you think the web sucks, then by all means, I encourage you to make a compelling alternative.
I think this is a strong argument for the need for something like Applets, Flash, and Silverlight to be an open standard. I appreciate the argument you make, but I think the simple counter argument is the ability for the framework to be modified at the developers' collective whim rather than corporate concerns.
There's lots of times in my work when I will read minified JS code to debug a stack trace. Using the "Pretty Print" option it's not too bad. So I'm glad it's there.
Also transparency is not just about humans reading it, it's also about automatic scanning of the source, and in some cases automatic modification of the JS (for browser extensions or code analysis or etc). Those are useful things that are drastically harder using WASM.
Another feature (like WASM itself) which will probably be misused to create pages that are less usable and responsive than before. There are very good reasons why the language of the web is non-blocking.
I think you are misunderstanding things. This makes it easier for WASM-compiled programs to favor non-blocking mechanisms when being compiled. It's just that the source language might express this without an async layer.
The fact is right now if the source language has a notion of blocking calls, the when compiled to a non-blocking target like WASM it currently has to do a bunch of tricks that outright makes things slower. WIth these improvements, those "blocking calls" can properly end up non-blocking at the JS layer, matching what we all know computers can do.
JS stuff is non-blocking because of the original sin of Javascript (we have to execute all the JS before we can render a page, since there can be some document.body = ... nonsense in there). This is incidental to the programming model, and not some deeper truth about how things should be programmed.
Case in point: non-blocking `async` code in Javascript ends up sometimes turning into blocking code for performance reasons in specific cases (when awaiting an already completed promise, notably). Jumping in and out of an event loop isn't exactly efficient either.
It's not configuration though. Specifically, it's not configuration of the project in question, it's configuration for third party accessories.
If I'm writing an editor, I expect the config directory in the source code to hold the configuration for the editor, not .babelrc
meta is a much better name and they are "about" the project, not the project itself, so I disagree on that point. Though I agree it should not be hidden. I will start having a "meta" directory in my projects
But third party accessories are an essential part of any project these days, they aren't optional or afterthoughts. In that page they mention docker-compose.yml as once example. Most likely it's impossible (in its current state) to actually run that application without Docker.
Other things that would land in the folder:
- Files essential to building the project
- Files essential to running the test suite
- Files essential to developing on the project
IMO a "project" includes all those things. In your definition are those all "meta"? Does "meta" mean anything that's not source code?
it's fun that the online community is getting a crash course in how protests and strikes actually work. As people have known since forever, a strike needs to be all-in or else it's too easy for the company to replace them with strikebreakers.
There's been so so many bad takes of "oh why don't they just protest by doing X instead" and 99% of the time the answer is, because we already know that X doesn't work.
IMO the biggest takeaway I had after a layoff: Always try to navigate your career so that you are doing something valuable to the business. You can tell based on a lot of clues whether you're in a position that's valuable or if you're forgettable. Moving "toward the money" not only helps job security but it helps your compensation too.
Say for example your team has a stretch of a few months without any new high priority requirements or requests. A young developer might think, "Yay, finally we have enough time to do all that refactoring in the backlog." But in reality, that situation should make you very concerned.
reply