I'm sure many people have said this before in these threads. But they're well made and have a lifetime guarantee. Sure, $20 seems like a lot for one pair of socks, but not if you have them for life.
I think I've been getting daily^W weekly email reminders to write my 750 words for 20 years now... I really ought to stop fooling myself that "I'll make this a part of my routine, soon!".
This shouldn't be surprising. The economy, forestry, and healthcare are all examples of government intervention that introduces artificial distortions that make a situation worse than it otherwise would have been had natural balances been allowed to proceed without those artificial distortions.
They're also examples of places where a lack of government intervention can be harmful.
Wildfires are a problem in part because people, left to their own devices, build in places they probably shouldn't have. (Or plant eucalyptus in California. Whoops.)
Healthcare, unregulated, is where we get the term "snake oil salesman" and cocaine-based panaceas from; most of the places with more regulation of healthcare than the US like Europe have both cheaper healthcare and similar health outcomes. An entirely unregulated economy gets you something more like Somalia and Afghanistan's. etc. etc. etc.
Any intervention system can be used as an example for why you should intervene. Just as any intervention system can be used as an example for why you should not.
I'd say it's more a consequence of the need to put boundaries on the costs associated with developing the software. I've been in an internal development group where costs were not defined. We developed what the company needed internally, regardless of whether it was "worth it." If the budgeting people knew that the silly app created to ease their yearly budgeting process likely cost 30-40k of developer time, it wouldn't have been built since it likely saves 1-2k per year of their time. But quality was good because we didn't need to build it in a week at a cost of 2k.
I'm not saying that's a good thing. But my point is that quantifying those costs for external customers means that corners are cut and speed is essential. _That's_ why the code is low quality.
I don't believe that "true" Agile is the reason for it. Referring back to the Agile Manifesto has allowed us to focus on what's important. Other Agile (Scrum,etc.) in the workplace is no different from waterfall or any other method since it is ultimately applied by those focused on the money and then fails for the same economic reasons.
I would agree with that in general. It's not the only reason I would say. Quantifying can be good. In an internal non-quantified project you still have constraints on the number of people you have around to build stuff, so there are still timelines to meet, because you can't build for the other department's needs if your people are still building that first piece of software. I'd go a bit further and analyze your parent's "reasons" in that light:
Mantras like “Working software over documentation”
Fluffy documentation that has nothing to do with the actual software as built (aka "out of date" or "waterfall spec that took 9 months to create and that nobody updated when it turned out we had to build it differently in the remaining 3 months of project time" etc.) is bad. And that's what this "mantra" is about. Whether it's an internal or external and quantified project, you had 12 months to build it.
the constant push to shove demos in front of customers
It's a good idea to demo to customers, if you can, because your customers can tell you if you're on the right track while you are still building, instead of telling you that you built the wrong wooden staircase after 12 months only. They wanted a metal ladder. Whether that's internal or external doesn't matter. It's always a good idea and I would argue that it's easier with internal customers. I.e. very easy to go over to Joe that works for the department you're building this piece of software for. You met him at the x-mas party last year and from time to time you eat lunch together anyway.
the battle for metrics
Hard agree. Pure reliance on (usually badly chosen, incomplete set of) metrics is absolutely bad because there will always be some high enough people with not enough understanding of everything that will rely on those metrics and those metrics alone to make (bad) decisions.
the idea that everyone needs to be “full-stack”
Not everyone needs to be full stack. But I do believe that you have either be full stack enough to understand the system from top to bottom or be really good at communicating w/ the other people in the stack to figure out how to build the system properly.
Building software is analogous to building a house. Sure you can make it look good and deliver that to your customer, but poor build quality will eventually be exposed during your first hurricane or earthquake.
If we want to stay in this analogy, there's one thing that can help a lot. And that is to actually start building in vertical slices instead of horizontally.
A house is not build horizontally. It's built vertically. You build an entire "feature" from the bottom to the top. First feature of a house is the structure. You build the walls for the basement, put in a floor and build the first floor, then same for the second floor and put a roof on. Structure done. (I may get the order wrong because I don't build houses) The next feature could be plumbing rough-ins. You can probably parallelize this feature w/ the electrical rough-ins and you build it from bottom to the top/vice versa but you build the entire feature. Only after that do you build the entire insulation feature, again from top to bottom/vice versa. Rinse repeat with drywall (another feature). At each of these steps you can either rush it, make incorrect decision, try to save money and do a bad job or do it with quality. You might use 2x3s for the structure instead of 2x4s. You can use aluminum wiring instead of copper. You can use R2 insulation etc. Luckily in house building there's a building code.
In software that's the same. If you build horizontally, you need to rely on things like designing and documenting APIs very carefully, build to spec etc. Basically you're just doing mini-waterfalls and calling it Agile or Scrum or whatever. But it has all of the same problems. The guy that built the xyz API last month and is now working on something else. Finally the UI people got around to building the xyz UI on top of the API and are discovering all the shortcomings in the design, the bugs that weren't apparent when "they tested the API" etc.
Build it vertically. Build the xyz feature from top to bottom/vice versa i.e. build the API and UI at the same time. The people doing it either need to communicate very well with each other or someone does it full stack. Doesn't matter. But skip the documentation and just build what you need in tandem. Build it well. You can use the same technique as with the house. The fun part in software development is that it's much easier to split these vertical slices into much much smaller parts. In the house you were only able to split the "rough in" feature into "Plumbing rough in" and "electrical rough in". In software the xyz feature can probably be split into many many more parts that can each be done in a very small amount of time. At each step you can decide whether you've been building the right thing, the wrong thing (and stop) or something that just needs some adjustments going forward. Just as in house building, you can do each of these vertical slices either with or without quality. Unfortunately there's no "software building code" w/ inspectors ;)
And if you build vertically, you can use your house err I mean software before it's finished. You can probably not move in right after the structure feature is finished. But you may, if you're fine cooking w/ the BBQ and use a porta-potty outside. You probably don't really want this if you have a family. And you don't want to ship software in this state. But after you have the plumbing and electrical done and the house is weather proof, you can cook w/ a small electric cook top, you'll have a sink and a proper toilet. You have drywall and heat. In many new houses you even opt to leave some of the features out completely in some areas. Like an unfinished basement. You can ship software that way too.
EDIT:
And even the Full stacking works in this analogy. Think "structure" part of a house. Your basement is poured concrete. That's done by a specialist usually, think of this as your DBA optimizing the SQL queries (or nowadays a BE guy w/ lots of experience in that). The framers build your walls and roof structure (trusses and such). These could be seen as your "BE guys" and the roof itself, i.e. the plywood and shingles or metal or whatever is put on by specialized roofers, these are your FE guys. Now if you have the skills and are full stack, you can build all of this yourself instead. Even if you build a whole house you could but let's say you just build a shed. Same as a house really, just everything is smaller and easier. But you can totally pour the pad for the shed (or the basement of a house but you will want to use a "library" or "framework" err I mean a company that delivers concrete by truck. You can frame a wall by yourself. It takes longer if you're talking whole house, but shed is not much slower when building alone vs. a crew. And you definitely can put on a roof. For a shed, you easily build a lean to style one yourself. You might use a "library" err I mean a company that delivers pre-built trusses for a house. And if you're building a lean to shed, anyone can lay plywood and shingles on that. If it's a whole house you probably only want to do that if you're good with heights. Maybe you're not full full stack but you can hold your own for smaller tasks.
This certainly isn't going to be right for everyone, but I downloaded the docker container for searxng a week or two ago and I've been using that. It's not the best solution for most people, but I've been very happy using that. You can read about it at docs.searxng.org
No. You're right. It's open. It's private. But it gets the data from other search engines. I was thinking of it from the perspective of a private and open source tool for searching. I was not thinking of an actual "search engine".
Those "other programmers" that are "harsh critics" are often ourselves. How many times have you (any programmer) looked at your own old code and thought, "what they hell was I thinking?"
I can't count the times I've looked at ugly code, fired off `git blame`, and found out it was me.
I believe it's the opposite. Every shared account increases my exposure as the user. If I have 500 accounts across 500 sites, and one is compromised, 499 are not. If I have 1 account across 500 sites, and that one account is compromised, all 500 sites and the data I have there, is at risk.
Though real world evidence suggests that the more accounts you use the less likely you are to use strong passwords and the more likely you are to reuse passwords.
It's not a big difference if because someone has 500 accounts they have 1 password across all 500 and a breach of one account is still a breach of all of them. With the added fun that dealing with that breach requires 500 touch points to change passwords.
You may not personally be in that situation. If you read HN you probably use a password manager. The average user generally is in this situation. Consolidating accounts decreases their exposure of weak passwords. It's a different conversation if we are using something stronger than passwords, but today 500 passwords is inhumane and increases the attack surface of average users.
If you're just going to enforce MFA on weak passwords anyway, what do you need the weak passwords for exactly?
This is almost the exact line of reasoning why Microsoft, Apple, and Google have (finally) all agreed to work together to eliminate passwords altogether. Which probably is the only way that we can solve this: eliminate passwords, use proper keys and attestations instead of passwords, and try to make the user experience as nice as possible and at least no worse than yesterday's TOTP 2FA.
(And yes, there are lots of valid complaints for power users that know how to use a password manager today that any such key management platforms would be a worse single point of failure than their existing password manager because it would be more opaque and harder to user-manage/export. It's an interesting trade off for average user security, at least.)
Does your company culture expect immediate response? I like it because we treat it like short-form email, maybe with a slight expectation of quicker response. If I send you an email, it will have some detail and please get back to me within a few days. If I send you a slack message, I expect a sentence or two and a response today or tomorrow.
I've never worked anywhere that didn't expect an immediate response from Slack. If they wanted a delayed response, they'd send an email.
Worse yet, if I try to enforce that myself by not responding, there is a whole conversation in the channel before I get there and then I have to respond to all the messages in a mess of threads or some big long response block.
My work uses Teams with the expectation that a message is async. Most people respond whenever they finish their current task or meeting. Response times would generally looks like a bell-curve with the peak around 30 minutes. Some messages have the expectation of requiring an immediate response (e.g. reception who may be relaying information from an external phone call).
Typically when something is actually urgent, we click the call/video-call button instead of sending a message.
I think part of it is cultural. At $PREVIOUSJOB we used a lot of Indian outsourced devs and they were quite big on the "hello" thing. Could have been what the outsourced company told them to do, too, but they did stop after being asked to, mostly. QA seemed to hold on to it. They were predominantly women, so not sure if that played into it.
How would one do that exactly? Like I said, I could just not respond right away, and then I either have to respond to a whole discussion later in a mess of threads, or ignore it, but either way I'll get labeled a bad communicator and hard to work with.
Don't talk to each team member one-on-one, that'll never work.
Talk to your manager, make it clear in terms they understand. That doesn't mean complain or whine to them as that will just push them away from the point that you're trying to make.
You need to REALLY make it clear to them not in your terms, but in their terms. Show them that every time they do this your productivity goes down. Show them that if it's happening to you, it's also happening to others too. Show them the research that says interruptions are bad. Show them the communication models that other companies are using that work.
Your manager isn't going to do the research for you, they're too busy managing others. The only thing that managers are trying to do is to reduce the complaining to a minimum. If that means the minimum is only you complaining, then they are going to optimise for only you complaining. If you actually show them the research, show them a list of rules, show them a plan that can be implemented, then you complaining is always going to be the minimum. You need to show them that if they follow these steps, then the complaining will essentially go down to zero, only then will they act on it.
With that attitude you will. Honestly though you need to find a communication pattern that works for you and your teammates. In most situations if you communicate your needs clearly you won't get much pushback. For instance closing your instant message and email except for periodic checkins and letting people know why might improve the situation.
You could start small and block off a certain chunk of time during which you won’t respond. And communicate that to people ahead of time and the reasoning for it. Also set your statutes msg during that period. It could catch on and more people could similarly block off certain periods.
I find that even where immediate responses are not required where I work now (and, honestly, everywhere I've ever worked), the Slack status works pretty well for when I'd like to have some "me time". I usually set it to something business or "current fad" friendly, like "in my flow state - not monitoring slack or email".
I think a lot of the value in both Slack and Teams is the ability to seamlessly switch from async to real-time conversation, up to an audio/video call. Async should definitely be the default expectation though. Setting status flags can be useful for this. If they want and need an immediate response, they should call me.
I very much have “deep work” time where I turn off everything. If there is a house on fire emergency, they can use our paging app that can bypass DND on the phone.
Could someone explain how you don’t lose track of a message irretrievably in Slack if you don’t respond to it right away? There doesn’t seem to be any way to ever find anything again without looking through every single channel and DM conversation once it’s read — no way to see every message you’ve received by date or anything like that. And DM conversations just drop off the sidebar entirely if you have too many of them.
> Could someone explain how you don’t lose track of a message irretrievably
> in Slack if you don’t respond to it right away?
The idea behind "no immediate reply" isn't that you read a message and reply to it later. The idea is that when you're ready, you open Slack, then read and reply to messages. You then close Slack, go do a task, then come back to slack.
I dislike the split in Teams between chat and the Teams tab, but at least it has the Activity stream. Also you can mark messages as Unread so you can go back later.
Realizing there is no "perfect" helps. If you realize you'll never get there then you start to realize the diminishing returns the closer you try to approach.
I'm sure many people have said this before in these threads. But they're well made and have a lifetime guarantee. Sure, $20 seems like a lot for one pair of socks, but not if you have them for life.