Some of the worse engineers I've ever interacted with had too strong of a "taste" for what they felt were right and were completely unable or unwilling to work outside of that. Developing a superiority complex because you think you have "taste" is a great way to torpedo your team.
Coding for others is not art, it does not have much meaning in of itself. Your users won't marvel at your choice of language or your usage of design patterns - they care about how the end product looks and works.
In a world like that where you have to work in a team, why you ever wear your inflexibility as a badge of pride? The ones who are the most useful are the ones who can code any way, any how, and can plugin anywhere - "taste" be damned. If you want to be a net positive on the teams you work on, stop thinking it's about you, because it's not.
It absolutely is, and I think it's what separates good from bad and junior from senior devs.
Most devs can produce an artifact that more or less works. But one that has an internal consistency others can understand and extend, one which accurately captures the problem as it exists and ways it will likely change, is much more of an art form.
A big part of that is knowing which situations are worth making a stand. Every you write code or leave feedback, your doing it for your team current and future.
Nothing that you talked about pertains to art. Writing good code does not mean you're making art.
You shouldn't strive for internal consistency with yourself, you should strive for external consistency with the other developers in your team. If someone reads your code and immediately knows it was you, you probably aren't doing a good job.
And that's the difference. If you are doing a good job as a software engineer, no one should notice you. If you're making good art, everyone should see you. And that is the difference between devs who think they're good, and devs who are truly good.
Code can be art but not all code should or even could be art. Like there is just zero utility or elegance in formatting your bash script with pretty comments and some elegant data model if it’s just something you run to manually pull metrics from a staging environment or whatever.
I see code more like rocks, nails, planks, tape, shards of broken glass, and a pile of signs that say things like RADIOACTIVE - DO NOT ENTER. If you need to do something cool with that stuff you probably do need to create something that looks pretty interesting and elegant in spite of your choice in building materials. But sometimes you just need to take a NO TRESPASSING sign and tape it to a plank that you jam into a pile of rocks. Don’t need to find a hammer if you don’t use nails, only need it up for a day, just one of a hundred things on your plate to do something of bigger scope and impact - just make sure the rocks are big enough to keep the plank standing, leave and forget about it.
Spot on! The real difference between having great taste and just thinking you do lies in understanding the user's needs deeply. Good design isn’t just about looking pretty; it’s about nailing that value. And yeah, it’s no walk in the park!
> Your users won't marvel at your choice of language or your usage of design patterns - they care about how the end product looks and works.
Yeah, but if the patch is unreadable slop, some tasteful choices that make the code more maintainable will make features and bugfixes come faster for users and number go up for the business.
Unreadable slop and "tasteful" choices are independent of each other. You can make "tasteful choices" that makes code unreadable (I know from experience).
Readability also has some level of objectiveness to it. There's only so many ways you can abstract a concept, and so many ways you can express logic.
In that sense, readability has way more to do with skill in abstraction, than taste. In fact picking bad abstraction layers or expressing logic in odd manners because of taste is a great way to write unreadable slop.
At the end of the day, they're subject to the same market forces. If the big publishers lose their shirts, that means small bloggers don't have any chance of making it big. The same market forces that make big publishers worse are going to squeeze smaller outfits and writers.
And I know some people are going to say how writers and news "don't deserve" to make money because they haven't sacrificed enough upon the altar of tech, hustle, and Silicon Valley - I don't really care. I think newspapers and writing in general losing out is a blow to society.
I ride Muni, BART and Caltrain all the time (I'm car-free in SF), and I have no idea what you're talking about. Here are the actual statistics of crime per vehicle mile on Muni: https://www.sf.gov/data--crimes-muni
Crime in SF and other big cities have been going way down. If anything, you're probably safer than ever in SF (and other common political targets like NY and Chicago).
Also, how can you know that Muni is more dangerous, if you're too scared to even get on in the first place? Can you really say your fear is based on facts and experience?
He's probably talking about the walgreens on 4th and townsend and that area (also near where i live) has been getting worse in the past year. It was 1 of 2 neighborhoods that had an uptick in crime to the tune of 50%+. https://www.sfchronicle.com/crime/article/sf-neighborhoods-d...
Ditto. I ride Muni (bus and rail) in the Mission close to every day, and although I sometimes encounter people behaving erratically or anti-socially, I don’t recall the last time I felt “unsafe.” (Not that it’s always a pleasant experience, but it’s fine, and cheap.)
Just because the shareholders didn't vote on it, or an exec didn't explicitly say "hey steal this" does not absolve the company. Leadership doesn't get to throw up their hands and say "not my fault" when something bad happens.
It is ultimately the responsibility of the company and its people to create a system where things like this are discouraged or prohibited. Not doing so is tacit approval, especially in this case where they have a significant history of doing the same thing.
It's fine that you think corporations are supposed to work that way, and I don't necessarily disagree. But they don't in practice. They don't feel the consequences of bad actions because of legal economies of scale. They also don't backpropagate consequences from the company's bottom line to the individuals responsible. If you were to rectify this so that it works exactly as you envision, you would have made incredible advances in the Principal-Agent problem as it pertains to corporate compensation.
Most corporate actions that 3rd parties consider "bad" are the result of someone inside the corporation having an asymmetric payoff from directing the corporation to do the bad thing. They get the upside from a success, but not the downside from failure.
If you want to stop a certain bad behavior, your best bet is to change individual incentives.
I think the point being made is that the executives are either responsible for the company, or they're not actually running the company at all.
Like this isn't some tragedy of the commons situation. This isn't some situation where the company is a cooperative confederation of equal partners. Either shit rolls uphill, or you don't have leadership at all. You don't get to pass the buck on criticism because you made a decision out of self interest, either.
"It's not technically illegal," is the most blasé, low-effort rule for behavior. It's why only twelve-year-olds and lawyers use it as a defense for poor behaviors and poor ethics.
Being a POS earns you a reputation for being a POS, and that includes people publicly pointing you out as a POS in public forums.
> or they're not actually running the company at all
Executives are not micro-managing day-to-day implementation decisions of every team, no. They set broad strategic goals, the management layers below them decide how to best operationalize those goals, and the layers below those middle managers make specific implementation decisions to execute those operations.
If you want to think of this as "not actually running the company at all", you're free to. The point is that's how the world works.
Microsoft has north of 100k SWEs working for them, the idea that corporate management could be personally responsible for the decisions of every single one is absurd.
It’s not “CEO must know everything a junior does”, but more of “If a junior messes up doing something for the company, the CEO is finally answerable” - be it to the board, the govt or the public etc.
Rephrasing it - there’s a reason it’s Zuckerberg and Pichai and Tim Cook who go to congress, and not the folks implementing it on the ground level.
This post isn't popular, it has already fallen off the HN frontpage never to be seen again in any context. It did not and will never break into any sort of traditional media.
Not a single Microsoft C-suite exec, or anyone within spitting distance of the C-suite, will ever hear about this. Do not mistake your personal media bubble for the general media ecosystem.
In reality executives are responsible when the company is doing well. When mistakes happen it is either handled by insurance or by firing an employee who was only partially involved.
My observation ( for other such (similiar) war events) is that investigations by the instigators country will lead to very less serious punishments for the instigators and "down playing" of the harm from such events
If you’ve funded Abu Ghraib (by paying the US government) then you’re criminally culpable. And don’t try the Nuremberg Defense on me: “I was just following orders to pay every April 15”
Indeed. Hence "just following orders". Ultimately, I don't believe in this kind of strong culpability but it's clear the people who claim they do don't either and just bring it up when convenient.
Yes, have a moral philosophy which does not lead to total contamination across the interaction graph. It’s okay to pay taxes into the US Government even if some representatives of it act poorly.
But you said "Indirectly is sufficient. You're paying for it to happen.", when I was talking about taxes. What if I have a moral philosophy but my taxes still go to whatever is we are being against? I am indirectly paying for it, but it is coercion, IMO. The "vote for someone else" does not play here, another head of the same dragon.
I was taking that position to illustrate that moral contagion inevitably leads to a declaration of everyone being immoral. Therefore, moral contagion is not a useful differentiator between people.
Anyone else hosting MCP servers in a generally available way? Seems like that's the end goal given the network transports (especially the one in new spec revision).
Seems like everything I find requires running locally or hosting your own instance.
We did this because of a painpoint I experienced as an engineer having to deal with crummy mcp setup, lack of support you have no idea how hard it is to set up SSE, deal with API keys and scope issues, and then to find things like the tool that you want isn’t even coded yet.
And so one of the areas we found it to be useful was to do the soft communications with tools like Jira linear slack - updating stakeholders and all that friction that engineers hate doing. Some other areas people use a lot of tools with sequential thinking
Mostly for workflows that I like:
* start a PR with a summary of what I just did
* slack or comment to linear/Jira with a summary of what I pushed
* pull this issue from sentry and fix it
* Find a bug a create a linear issue to fix it
* pull this linear issue and do a first pass
* pull in this Notion doc with a PRD then create an API reference for it based on this code
* Postgres or MySQL schemas for rapid model development
Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on
VC funding is for sure less personal risk, but I don't think the other points are universally true.
1. Re: hiring, you're probably not going to hire your first FTE right after raising money. You're probably going to do so after getting a bit of traction. I hear most investors especially today will push you to be lean and do more yourself. Either way, bootstrap or VC funding, you're going to bust ass, no way around it.
2. Re: salary, yes, some investors will encourage you to pay yourself, but you're probably not paying yourself a "full" salary right away.
3. Re: selling to cohorts is a bit overrated I think. The fact of the matter is, they're probably all early-stage tech startups, which means if you don't have a product that specifically targets early-stage tech startups, you're probably not going to sell to them.
I don't think it's as cut and dried as X is better than Y. It really is all about how much risk you want to take on, if VC funding is even an option.
Is Rust praised for its checked errors? I've personally found it extremely verbose since there essentially is no possibility for unchecked errors.
Also, external crates like "anyhow" are required if you don't want to account for literally every single possible error case. Really seems like a pedantic's dream but a burden to everyone else.
Effective Java recommends checked exceptions only in the case where the caller may recover, but in practice you're usually just propagating the error to the caller in some form, so almost everything just becomes unchecked runtime exceptions.
I'm only saying what I've seen here. I typically see praise for Rust's checked errors. Especially since they provide ? to panic and uncheck them. Personally I disagree with Bloch, if you are the thrower you can't possibly know if the caller can or cannot recover from your error so in my opinion its best to check it. If you are not the thrower and you can't recover from it I prefer to uncheck them, because if I can't recover my caller most likely can't either.
The issue really just arises with Java not giving you the capability to uncheck that error easily if you can't recover from it. For example, you need a ton of lines to uncheck:
A doIt() throws B {
throw new B();
}
void usingIt() {
A a;
try {
a = doIt();
} catch (B b) {
throw new RuntimeException(b);
}
a.woohoo();
}
My ideal situation would be for some sort of throws unchecked operator (or whatever syntax we want to bikeshed over) that turns them into unchecked exceptions.
void usingIt() throws unchecked B {
var a = doIt();
a.woohoo();
}
Have you heard of the language elm? The language elm is so safe that it is literally impossible to crash the program short of a memory error.
That's essentially the direction of modern programming languages. It's part of that feeling you get when programming haskell. Once you get it running, it just works. It's very different from the old paradigm where once you get it working, it can crash and you have to debug and do more to get it working better.
How do you even "fix" loneliness? If you don't know that, you can't allocate resources. Plenty of research studies have been done on loneliness to find a silver bullet.
For most people, it's not like there aren't opportunities to meet people and talk to people. It's well understood that no matter how many people you get exposed to for a period of time, meaningful relationships can't be forced.
Plenty of lonely people in big cities going to social events.
Yes, I do agree that not knowing how one can solve it is a huge contributor to nobody trying to solve it.
But the entire article is complaining that we should stop trying to solve it so we can go do something more important. So, the entire article is high-order bullshit.
Just this bit:
> For most people, it's not like there aren't opportunities to meet people and talk to people.
Coding for others is not art, it does not have much meaning in of itself. Your users won't marvel at your choice of language or your usage of design patterns - they care about how the end product looks and works.
In a world like that where you have to work in a team, why you ever wear your inflexibility as a badge of pride? The ones who are the most useful are the ones who can code any way, any how, and can plugin anywhere - "taste" be damned. If you want to be a net positive on the teams you work on, stop thinking it's about you, because it's not.