I totally agree with this. I am in a situation right now where the skip level manager is asking to schedule meetings every other day to talk on a problem that requires research. They want to talk about a solution and not letting us find one. Another one is defining aggressive timelines when I don't even know what to solve. Obviously the timelines were shot to hell in the worst way possible.
In the same boat. It's painful, whenever a bug appears or there's something they don't understand; boom! A meeting gets scheduled. It kills the soul nevermind productivity.
The other one is having to answer the same questions over and over.
When you're about to go to production, tests have been written and everyone's done their part, you'll get asked, "so you're sure nothing will break production?" It blows my mind.
In the nicest way possible, get those meetings canceled. Show initiative by simply saying "I will provide an update by the end of the week; let me do my research first."
If the skip-level is refusing to stay out of your lane and not let you do your job, it might be time to dust off the resume. Thankfully, the market is crazy hot for anyone not a junior. Still, that sounds bloody awful; I am sorry you are going through that. :/
And in the best way I can say this, but deadlines don't matter if they are not set by your engineers AND accounting for the time to add unit tests/integration tests/bug fixing/clean code. I've inherited plenty of salvage projects with terrible codebases that eventually get scrapped wholesale and redone from scratch - so if someone tells me to cut corners for bullshit deadlines, I'll push back with those stories and keep the course. Call me cushy/inflexible/unrealistic, but I refuse to write a salvage project of my own.
It's a mentality and culture difference. Manager-type people solve issues by having meetings, lots of meetings. Their work is accomplished in the meetings. The can have 7 meetings on the same day, each about a completely different subject and still manage to get something done.
Programming on the other hand requires uninterrupted blocks of time. Working on 7 projects on the same day just means you have 7 projects that didn't progress. Having to sit in a meeting every other hour means you're not getting anything done between meetings because context switching takes time.
I have an HP laptop with a 3rd gen i5, fairly low powered repurposed with Linux and Plex as a home server. I am using it as a media server, file storage with hard disks attached and also as the primary tailscale host to have a mesh of personal devices over the internet without a public IP.
I like the idea of beginners terminal. To make them used to using keyboard instead of hunting for icons and menus. Once they are comfortable, they will find faster alternatives and end right back to the default plain terminal.
The inflow of new engineers which are not so familiar with traditional tools like a basic terminal and a text editor. That was all which was needed to write software. Most of the software stack was quite flat back then. Today, the way everyone starts is by installing a bunch of tools, frameworks and an IDE to navigate through those tools. Even a simple web page requires to install 100MBs of dependencies. Trying to learn those tools from scratch is not useful because it's all abstracted and is almost never dealt with. These terminals are making the use of those tools simpler using features like autocompletes, suggestions, metadata about the command etc. It's just like how an IDE became necessary for some languages like .NET or Java because it was no longer just the language. For terminals it's now good 'ol coreutils vs a bunch of npm crap.
I personally don't like to use pimped up terminals because they are written in electron and are not portable. The whole point of using a minimal terminal is being snappy and portable. Just like engineers today can't write code without autocomplete, new engineers won't be able to navigate the cli without assistance.
An analogy would be, vim purists with 0 config vs people who have elaborate configs.
> An analogy would be, vim purists with 0 config vs people who have elaborate config
I find this pretty offensive. I have a vim config that automated my workflows, and integrated linters and build tools etc...and I am using Linux based systems for over 22 years now.
While I consent with the rest of your comment, I think that most people don't want to deal with shitty syntaxes that are less memorable than they should be. Computers and TTYs have moved far beyond 80 character screenlines these days.
Having a -s instead of "sync", for example, doesn't make sense from the UX perspective. Most of the reimplementations of common CLI tools of coreutils and others are mostly there because they were fed up with inconsistent parameters, options, and flags of those programs that have historically grown out of proportions.
On the other hand I can also understand why people use zsh, even when I don't like it because I'd consider myself a minimalist. Though I also have a lot of aliases for common tools I use, because I would go rogue when I would have to type all those parameters on a regular basis.
The issue most terminals try to solve is explainability and predictability, because they see terminals as a human interface, and not as a tool to write yourself one.
The clashes of those different philosophies are also found in shell implementations. I mean: off the top of your head, do you know all string manipulation syntaxes in bash? Probably not.
vim wars. I am on the vim side. I don't care about vscode that much. The only gripe is the first class support vscode gets in terms of plugins as compared to (neo)vim.
The vim purist having 0 config wasn't my original thought. I had heard about it before and I have seen talks where the speaker would do everything with default vim syntax and not use plugins or maps. I personally have a bunch of plugins and shortcuts because I can't touch type. so I need most used keybindings close by.
I agree the inconsistencies with coreutils. Having helper tools and scripts vs spoon feeding with all options using arrow keys. Just the extremes, having aliases is all good and I never remember awk and sed syntax.
> I personally don't like to use pimped up terminals because they are written in electron and are not portable.
Alacritty, Wezterm and Kitty say hi. Uber-fast native apps that also render all the modern Unicode symbols correctly (well OK, Kitty has some Python).
You are also over-exaggerating and coming across as the "get off my lawn" guy.
I am 42, I was there when terminals were as bland as non-salted spaghetti in boiling water with nothing else in. Nowadays I like the autocompletes (with context nonetheless -- a huge improvement; you can autocomplete GIT verbs for example), I like the fuzzy finders that I integrate with (a) looking for files, (b) looking in my command history, (c) looking in my OS process list and (d) looking through all modified / untracked GIT files in a repo, I like the colors, I like the icons for separate file types, and I like modern incarnations of coreutils whose output provides you visual aid that objectively reduces the amount of parsing that your eyes must do on the screen. Eye and mind fatigue are real and all visual aid [that's not overdone] helps a ton. There are even scientific studies on it.
Want me to go on?
Conservatism like yours is not productive. Like with everything in life, there's good and there's bad e.g. I won't ever use the terminals that are written in Electron and phone home -- that gets an immediate "NOPE!" from me -- but there are objectively useful terminals, terminal extensions and CLI tools out there.
That you judge all of them by a few hip repos that are making the rounds here on HN only says something non-flattering about your abilities to gauge innovation.
Be more open-minded. It helps in an objective manner and with objectively improving metrics to show for it afterwards. At least it did for me and 30+ colleagues.
I use Alacritty full time (tried kitty, didn't work with my workflow), personal and work. I am not ruling those off. I don't mean to come as mean and conservative. I just don't like the over emphasis on "spoon feeding" tools across media. I know there are much better tools which can help with productivity. But, new engineers are only going to pick tools which are "marketed", the "hip" ones without weighing merits. But for sure, whatever works for them, who am I to judge.
I too use a whole lot of tools to keep the output less messy and I know some tools which have changed my life, ripgrep, exa, neovim, zsh, alacritty, git extensions, fzf and what not.
I'm baffled by the repeated insistence that alacritty and kitty are fast (never tried wexterm). There's noticeable lag spawning either on my reasonably new and fast laptop, which xterm just doesn't have.
When I need a terminal, mod+enter spawn one and close it. I'll often do this to download a file, start yt-dlp, mpv etc. The session is all tmux so I never keep the window around when not in use.
Me too. On my systems, running Debian with dwm, a Kitty terminal appears instantly. It’s the fastest terminal I’ve ever used, by a big margin, including xterm. The fact that I can do things such as ssh into a remote machine and see an image in that machine’s filesystem displayed in the terminal are bonuses. I mainly use it because of its speed and Unicode support.
Sure, if that's your workflow then I get it. I and many others keep around several persistent windows or tabs however. I don't care if Alacritty takes 1s to start.
Still doesn't invalidate its usefulness, too. Alacritty in particular is often times a better Unicode-rendering citizen compared to other terminals.
> The inflow of new engineers which are not so familiar with traditional tools like a basic terminal and a text editor.
I think many people start learning to use these tools at the same time they learn to program, I know I did. You expect junior devs to be terminal wizards?
> Even a simple web page requires to install 100MBs of dependencies.
No it doesn't? Some tooling requires lots of dependencies, but it's still very possible to open a text editor and spin up a web page.
They aren't literally claiming a physical requirement, they are describing todays most common workflow.
If I said you need to install 100's of mb of gcc to produce a binary, would you say "no you don't? you can write bytes directly from the shell right into a file" It would be a technical fact, and yet kind of stupid to pretend not to understand that today, in all practical senses, one produces a binary with a compiler suite of one sort or another.
Today, it's a growing trend that software is developed using huge ides and stacks of frameworks. And a new developer is started right off at the highest most abstract (most automatic and magic, sold as most "productive" or "practical") layers possible, which requires the fattest of ides and the tallest of stacks.
Yo! exactly my point. I never expect new devs to be experts. But the labor I am spending to teach one of those newbies (well 1.5yrs of experience) about how to check for a port listening is just astonishing. Being a whiz and knowing the basics of the environment you are working with daily, there is a difference.
I understand it takes one text editor to write a static website. But hear me out, If you asked a dev today to make a landing page, they look for templates instead of writing that stuff. It's possible, but it's not probably today. Everyone is going to whip up a react or it's derivative to even write a simple project.
> Even a simple web page requires to install 100MBs of dependencies
I had problems with having to log in to a bunch of audio encoders last weekend to find out why they were engaged.
I looked at the webpage, a few calls with http/digest returning xml.
I strung together a quick perl script to take an ip/user/password, fire it off to the device, decode the output, fire off more queries, and dump out a <tr>, and then wrapped that in a bash script which generated the rest of the page for the N devices I wanted the status of. Took less than 60 minutes. Deployed it as a new apache virtual host with +ExecCGI.
3878 bytes plus OS provided packages for things like kernel etc, and now I can save time again and again by looking at the status page.
You can choose to make a simple webpage to perform a simple task and have it take 100s of MB, or you can choose not to.
The purists got it wrong. The maximalist JS devs got it wrong. Imo the best way for most things in life is to have it as simple as possible without abstracting away everything, kinda like a middle path- like using zsh with autocomplete and highlighting in st, huh?
There are a few ways I think I could find gratification in what I do with computers. Building something that other people use (they could have complains, that's fine). Probability because of humans liking the feeling of being needed.
Encounter a problem and solve it with computers, even more fun, every time you or anyone hit the same problem, they use your tool and realize how easy it's now, that feels great.
You read code/solution/architectures and you go like "Damn! that's clever" or "Oh! that's so neat and lean" or "That made a lot of sense!". Basically, the hit you get from understanding something clever, that means you just leveled up and you'll remember that you understand it now.
Think about other people, how they would use it or whosoever is going to read it. You make it simple for them to read or an elegant solution to the problem. Being able to formulate something, anything, gives a good feeling.
In some sense, the above things are applicable to any field.
WW3 will require the involvement of atleast China and USA and then these countries pull in their allies because the battle ground is Eurasia. So countries like Germany, France, England, India because of resources and man power. At this point, the world is too fragile to afford an all-out war. One hidden agenda of war is to increase debt. US already has the reason for it, COVID. EU is sensible enough to not nuke it's own economy at this time. It's just resources at stake, Fossil fuels and earth resources which Russia controls but there are alternatives to it.
China could get into the war, it may even be in it's interest, fend of US and open doors for it's invasion in Taiwan because US/EU both support Taiwan. India and Pakistan getting in because then India will need to protect it's borders.
There is a very delicate balance between countries which we just can't afford to break. If that happens, UN goes into dumps and then it will be all Nuclear without any regards because at that point earth will have given up. So no more land to rule.
None of the above is based on facts, current political status, secret hidden families or anything. Just a random thought.
I like the key attributes part. The engineers are paid by the hour, so they are incentivised to have the project running for as long as possible.
I don't think it's cheap to get an offshore team to do because the engineers might be cheap but the whole team + mgmt + reviewers are expensive. I have heard stories (from a person who did work in such environments) that the managers would charge a ton and do nothing basically. The work was handled by engineers and was reviewed by offshore people. Not sure what the managers were managing.
There are 2 advantages of an offshore team, especially India,
- Round the clock work
- Contractors can be hired for a few months and don't cost as much in terms of benefits that the company needs to provide to full time employees. So when you know work is going to pour in for 2 quarters, hire a bunch of a contractors. That way you don't have to pay for the equivalent on-site staff all year.
But obviously, this only shows up in quarterly financials and it's hard to judge the quality of the product over multiple years and iterations which is abused.
They have to do it because VCs aren't going to stick around years for your organic growth. It was supposed to be a proof of viability and then proper quality product. With this model of money making, it's just the PoC.. no need for quality.
The whole stock market is just a speculation game now. With no real value defined behind it's price. All software and strategy is defined on finding stock at a higher price due to any reason. If you can't find a reason, make one. Like CEO's buying more stocks to limit the supply of their stock and propping up the "value".
It's all about the "sugar rush". Doesn't matter if the commodity is worth shit. The GameStop fiasco demonstrated that amply. It had no real viable plan, so it shouldn't have been worth a lot but you could artificially increase it's value.
