Hacker News new | past | comments | ask | show | jobs | submit | best comments login

> Stewart Butterfield, former CEO of Slack, recently described a dynamic within tech companies behind much of the over-hiring. He noted on Bloomberg’s Odd Lots podcast in late May that when there’s no real constraint on hiring, “you hire someone, and the first thing that person wants to do is hire other people.” The reason is that “the more people who report to you, the higher your prestige, the more your power in the organization…So every budgeting process is, ‘I really want to hire,’ and that to me is the root of all the excess.”

I’ve seen this first hand. One place where I worked HR even had a table of team size vs manager compensation. When I pointed out that it may not be the best idea to directly incentivize managers to hire more people they were less than understanding. Of course it went totally out of control.

But sadly there just is no counteracting force (except perhaps mr Musk). When you apply for your next job as a manager they will ask you “How big was your team?”, and they won’t be impressed when you say “I managed to keep it down to four people”. It’s just something that resonates very strongly with the primitive side of our brains (“You say you were the chief, how big was your tribe?”).


I work in academia. When we grade exams, the order of the exams on the stack is the order in which they were collected in the room (people can sit wherever they like). For grading, we are usually 5 people in a single room, and everyone grades a specific exercise for consistency. The exams are getting shuffled heavily, with everyone just grabbing stacks, looking for exams where "their" exercise was not yet graded, and taking them out. So basically, the order in which we grade exams can be considered random.

However, I also grade weekly exercise sheets during the semester, and these are committed into a repository, where each student has a folder that... begins with the first letter of their first name. Everyone I have ever worked with acknowledges that you have to shuffle the order in which you grade these submissions each week, for fairness. Several effects come into play: (1) your are usually less tired at the beginning, (2) your mood gets better during the last 2 sheets because you know you are done soon, (3, and crucially) at the beginning, you have not yet seen all the common errors / developed a "feeling" for them, and you might thus miss them in early submissions, but spot them immediately in later submissions.

Another alphabetic effect: In elementary school, my name was on top of the list of students in my class. I remember that I often had to do some special job simply because I was the first name on this list (for example, carry a group ticket when we visited some museum, keep track of something, be the first at something where nobody wanted to be the first, with everyone watching, be the first to be graded in PE, again with everyone watching, etc.). As a fairly shy kid, this already annoyed me in first grade.


Author here. Happy to answer any questions!

Some background info on the project: https://littleworkshop.fr/projects/equinox/


Great article. I just want to comment on this quote from the article:

"Really good developers do 90% or more of the work before they ever touch the keyboard;"

While that may be true sometimes, I think that ignores the fact that most people can't keep a whole lot of constraints and concepts in their head at the same time. So the amount of pure thinking you can do without writing anything at all is extremely limited.

My solution to this problem is to actually hit the keyboard almost immediately once I have one or more possible ways to go about a problem, without first fully developing them into a well specified design. And then, I try as many of those as I think necessary, by actually writing the code. With experience, I've found that many times, what I initially thought would be the best solution turned out to be much worse than what was initially a less promising one. Nothing makes problems more apparent than concrete, running code.

In other words, I think that rather than just thinking, you need to put your ideas to the test by actually materializing them into code. And only then you can truly appreciate all consequences your ideas have on the final code.

This is not an original idea, of course, I think it's just another way of describing the idea of software prototyping, or the idea that you should "throw away" your first iteration.

In yet different words: writing code should be actually seen as part of the "thinking process".


From the article:

>>> "Wouldn’t it be great if you could pay $9.99 a month and read all of the books you want?"

I sincerely hope nothing "disrupts" public libraries in my lifetime. As a California resident, I can walk into ANY public library in the state and get a free library card with access to physical books, audiobooks, ebooks. Some branches have laptops, hotspots, tablets, e-readers available to borrow. My local branch even has a Makerspace with 3D printers, laser cutters, sewing machines, and other misc tools.


Note that the author of this piece is also directly responsible for blocking the acceptance of many new features in Carto, including community-developed and broadly accepted features like highway=busway:

https://github.com/gravitystorm/openstreetmap-carto/issues/4...

Carto is of course just one style for OpenStreetMap, but it is also the default style shown on openstreetmap.org, with direct support from the operational team (server resources etc.). If a high-profile feature is not rendered by Carto, gaps show up all over the world where people use Carto-based screenshots, etc., and of course on openstreetmap.org.

The stagnation of Carto, and thus openstreetmap.org, the website, is one of the major pain points for many mappers and developers in the OSM community, including myself. (It also highlighted the failure of the OpenStreetMap Foundation to deal with this situation, although the recent move to develop a successor vector style is somewhat hopeful).

Personally, this makes me very hesitant to consider anything Christoph Hormann writes regarding OpenStreetMap in a positive light.


It's called "empire building" and is also part of the principal-agent problem where the manager is the agent and is assumed to have the firm's best interests in mind, but in reality doesn't. As a result, the principal (for example an owner) has to come up with methods to keep their management honest (example... tying most compensation to stock price - although I think this just makes management short sighted).

I was once in a meeting where an IT manager was told his group would have to handle the install for a piece of software that like 2 engineers used. The guy asked for 3 additional head count and my jaw dropped. If someone has ever seen the Avatar Airbender show, I was like Prince Zuko speaking up at his father's meeting. You see I was there as a courtesy and tried to point out that even one headcount seemed like a lot for something that should take less than a week of work for a single employee. At the time I didn't understand that the manager understood this, but was playing for more staff to build their own importance. I didn't understand the games they play. As part of the game...you always say your people are swamped no matter what...or refer to a massive backlog of work even though that backlog is all super low priority and existing employees can be reprioritized.


It’s not the “programming industry” that OP hates, it’s the “corporate world”. I’ve worked with (and have been) developers who have mismatched expectations on what “the real world” wants out of them.

The corporate world doesn’t give a shit about finesse, abstractions, witty or beautiful code. They care about finding developers who will pump out features to the business requirements. Some human beings in that cog (managers, directors, peers, etc) may allude to enabling developers to actually practice the “art” of programming but the bottom line is if you aren’t moving the needle economically for the company, you’re a liability.

Find comfort in programming outside of the corporate world and practicing the art but don’t expect the “industry” gives a damn about the how or why of programming, mearly the characters we punch onto the screen into cash. Once you come to terms with this, life gets a lot easier, less frustrating and you can actually find fun in the work (albeit, not necessarily “art”).


This is self-reported: remember the 1000 Indians that were watching people shop at the Amazon Go stores?

Amazon told us it was all "sensors" because it fit their company narrative to do so.

I am not saying that Amazon doesn't have 750k robots and hasn't laid off 100k people... but they usually have some seasonality, plus, the quoted number is from 2021, the height of at-home shopping.

"The world's second-largest private employer employs 1.5 million people. While that's a lot, it's a decrease of over 100,000 employees from the 1.6 million workers it had in 2021"

I think a bit of skepticism is in order, is all.


"Open platform" my ass. I still have to jump through ridiculous hoops to mod BeatSaber (which is the only way to make it worth playing for more than a few minutes). Quest 3 makes modding even harder. This announcement is trying to frame App Lab as an open app distribution platform; it isn't. Those "basic technical and content requirements" apps have to meet are basically the same ones that Apple or Google or Meta themselves enforce for their app stores. Entire classes of applications, particularly those that undermine platform-owners' business models are not allowed.

Additionally, Horizon is generally a terrible operating system. Useless and intrusive "social" features out the wazoo, laden with tracking/spyware, and it isn't even good for anything beyond launching apps that take over the whole environment. Want to use your fancy headset to open up apps in 3d space and do some multitaking work? Well I sure hope you're happy with exactly 3 2d apps (all equally sized) lined up in a row in a fixed location, because that's all you're getting. If you want to do anything real you need to install an app that launches its own environment for multitasking, but of course then you can only pull in windows from a remote PC, so if you want to run any local applications it's back to basics for you. Oh, and of course you can't mix those remote PC windows with local apps. As poor as Apple's Vision OS is in the multitasking department Horizon falls far behind even it.


I went the opposite way (in the UK) and moved from development (mainly C#) to lorry driving (everything from 12T rigids to 44T artics) however in my free time I’m enjoying developing (some RoR, some Golang) more than when I was paid to do it.

Although I’m working more hours (average 50-52 hours a week compared to 38-40), I’m also much better compensated doing HGV driving than I ever was as a developer (although that may reflect more on my skills/level as a developer than anything else)


I am not convinced. Reading the whole article it seems that Bayer is moving to a system better known as QBR, mixed with OKRs and most likely some sort of agile model.

There is no no-hierarchies. Working in a 3 month cadence on an organizational level puts a lot of pressure on all people. Usually QBRs work top down and there is more monitoring along the process.

What sounds great is more or less success theatre as well as inflexibility. No one wants to lack behind in a QBR report. Risking 4 times a year being red flagged in a report sparks fear.

Also approval processes and idea sharing are the first victims of such reorganizations. No one risks a 2 week sprint for some improvement sprint or working on technical debt in tech for example.

I’ve seen this within a company with 100k employees worldwide.

People will regret QBRs.

Usually companies want to get rid of the costs of middle managers, which are usually elder than normal staffers. Also companies want to include younger folks, because they are on average cheaper per resource from a controlling perspective.

Young guns without leadership with delivery pressure by an even older senior management layer means having a large gap and divide between them.

Senior management adds so called assistants to their staff, the hidden layer.

I watched a lot of mobbing at the lower level as a result. Fear of tumbling over mistakes aka receiving a bad performance review is rampant when you need to report all the time results.

Mixing teams every QBR sounds fun, but isn’t. It means even more being in constant competition. Who is the most flexible employee and most successful under different circumstances?

Large organizations are hard to manage. People will very soon miss their middle managers to cover things up in a human way.

QBRs don’t help if there is a clear product strategy missing.

There is no perfect system, but QBRs are some of the most toxic form of working and collaboration that I have witnessed so far.


Shouldn't the readme first explain what this project is about? How would I know if this is relevant for me/my work. Not trying to be obtuse, I am fairly new to CS and I would like to understand what I am looking at and how I could use it in future.

The 1000 Indians story was completely incorrect though. They has 1000 people in India tagging the videos after the fact for improvements to the machine learning algorithms. They weren't watching in real time.

their "merch store" https://merch.krazam.tv/ is losing out on a lot of potential revenue by not even making a reference to their most viral videos. Who wouldn't want to rock a Galactus shirt.

can we crowdsource merch ideas for these guys pls


I had the same thought as I read that line. I think he's actually describing Linus Torvalds there, who, legend has it, thought about Git for a month or so and when he was done thinking, he got to work coding and in six days delivered the finished product. And then, on the seventh day he rested.

But for the rest of us (especially myself), it seems to be more like an interplay between thinking of what to write, writing it, testing it, thinking some more, changing some minor or major parts of what we wrote, and so on, until it feels good enough.

In the end, it's a bit of an art, coming up with the final working version.


I'm guessing it's the opposite. Meta is trying to establish the same OS-level foothold/control that Microsoft, Apple and Google have.

This is because Ruby inherits it's approach to flow control from Smalltalk, while Python comes from a C/Algol-like heritage.

In fact, Smalltalk takes this much further, such that basically all flow control (including if-then-else) is handled as message sends (e.g. if-then is just a message sent to the Boolean object taking a block as it's argument).

The downside is the syntax can feel a tad clunky. The upside is incredibly simple and consistent language grammar, while making it trivial to create new flow control mechanisms since the language has all the tools baked in (primarily first class blocks).


This is called Parkinson's Law: https://www.economist.com/news/1955/11/19/parkinsons-law

"To comprehend Factor I, we must picture a civil servant called A who finds himself overworked. Whether this overwork is real or imaginary is immaterial; but we should observe, in passing, that A’s sensation (or illusion) might easily result from his own decreasing energy—a normal symptom of middle-age. For this real or imagined overwork there are, broadly speaking, three possible remedies

(1) He may resign.

(2) He may ask to halve the work with a colleague called B.

(3) He may demand the assistance of two subordinates, to be called C and D.

There is probably no instance in civil service history of A choosing any but the third alternative. By resignation he would lose his pension rights. By having B appointed, on his own level in the hierarchy, he would merely bring in a rival for promotion to W’s vacancy when W (at long last) retires. So A would rather have C and D, junior men, below him. They will add to his consequence; and, by dividing the work into two categories, as between C and D, he will have the merit of being the only man who comprehends them both."


Credit to this organization from pivoting (AFAIK) from their original plan to scrape the plastic out of the water on the open ocean ("System 001"). Intercepting plastic at river mouths seems much more practical and cost effective.

Disagree with most points. This seems like another "hyper-productivity" driven blog post that is so common nowadays. If you don't grind 10h and have a clear career path, you are a failure. Couldn't disagree more.

- Have good sleep habits. Sleeping 4-6 hours per day because of "productivity" is not cool.

- Don't be obsessed with "productivity" and "efficiency". It's okay to take days off and relax.

- Which leads to... Prioritize your mental and body health.

- Career path? Big aspirations? Nothing in life is promised except death; don't forget to enjoy every day. Build habits that you truly enjoy doing every day.

- Take care of your family and friends. Don't see people as a "network" to use for your own benefit. Love and be loved as a genuine human.

- Absolutely do write blogs and do some public speaking because you enjoy it, but not to clickbait people into buying your motivational courses.

In summary, find balance and true happiness for yourself. This post was sad to read.


I really think the fact that this kind of thing can be known and reported by a newspaper means we should have some kind of anti-corruption law triggering at least an investigation in cases like this. The fact that "lobbyists for [company] act to manipulate legislature against the public interest" is such a humdrum and daily occurrence is a problem

Interesting piece! I’m co-creator of Zombies, Run! so I’m glad to see it mentioned here - we designed it to be in the best interests of players, which is why it doesn’t feature streaks or leaderboards or other ways to manipulate you into overexercising or playing more than you want to.

That said, I’m more sanguine about gamification than the author. There are indeed many games to choose from, but the ones that are most concerning that those we have little choice but to play, whether they’re from our employers or in our schools and colleges, or built into devices and platforms like the Apple Watch and iOS.

If you’re interested in this subject, I wrote a book critiquing gamification called “You’ve Been Played” - the NYT called it illuminating and persuasive!


I recently started buying paper books.

Yes, it's not particularly ecological, but I found that I'm able to focus at the text much better this way. My Kindle (despite plenty of obvious advantages) just doesn't really work for me.

It took me years to realize this, but I always start to tinker with the brightness settings, switch pages back and forth, go into the book library and back, play with highlighting words, etc. I will do anything instead of reading the text. Meanwhile with a paper book I don't have an urge to flip a page back and forth and observe how it behaves. I can focus on the text.

Not sure why I am this way.


Not Mistral, for anyone else that reads the comments first.

Yeaaaaaah, remember when the bulk of US manufacturing and industry was offshored a few decades ago and pundits were falling all over themselves to explain how we were transitioning to a "service economy"? Well this is what a service economy looks like.

I loved biology in high school. I had one of the most boring teachers ever, and literally slept through class half the time, but then I would go home and read the text book for homework assignments and I found it totally fascinating. It was kind of running gag that the teacher could wake me up and ask me a question at any time and I always knew the answer, to the amusement of the other students. But my secret was just that I found it interesting and easy to absorb.

I don’t really like the idea of blaming others for one’s lack of curiosity about a subject. There are a lot of factors that determine how receptive we are to learning something - current interests, life experience, how developed our brains are, etc - beyond just the way it is taught. I have a much deeper appreciation for geology now than I did in school, for example, and I’m fairly certain that I’m the one who changed, not the way plate tectonics are taught.


What final enables is devirtualization in certain cases. The main advantage of devirtualization is that it is necessary for inlining.

Inlining has other requirements as well -- LTO pretty much covers it.

The article doesn't have sufficient data to tell whether the testcase is built in such a way that any of these optimizations can happen or is beneficial.


I'm not a fan of Microsoft, but this is some amazing blame shifting. The root cause of the problem is the government single-sourcing a vendor and being incapable of negotiating with said vendor. The US government is 10% of Microsoft's annual revenue just on security services (if I read the article correctly) but is failing to negotiate. The right answer here is if the situation is that bad, make a very public long-term commitment to shift to something else & up-level your IT department to be able to execute multi-year projects competently. Instead of meeting Microsoft on the business playing field, it's trying to use scary "national security threat" verbiage to try to bully them in the court of public opinion.

Regarding security, at the end of the day, the US government is a huge target for adversaries. You can't outsource your security practices & if MS software is really that much worse they should be fixing their purchasing requirements. The reality though is that whatever software the US government would switch to would become the focus of adversarial research.


The author could try forking and patching VSCode to fix the annoyances manually.

Years ago I had an issue with VSCode: it was missing a small feature that was very important to me, with the GitHub issue stuck in limbo.

I ended up going into the source and implementing the feature myself. It took a few hours after bugfixing, I think the fix was ~100 LOC. Then I used the locally-built version. I recall building took a while, and the source and artifacts took a lot of space, but no other problems.

I also created a PR referencing the issue and it got merged rather quickly. Someone else ended up finishing the work since there were some problems (I think relating to coding conventions, and possible edge cases I didn’t need or handle).

Maybe I was lucky for the feature to not require much edits, and probably for the PR to get taken over and then merged fast. But it seems like the author's issues are also small, and it would be easier and more ergonomic to patch VSCode than to create an entirely new debugger.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: