They had it a few years ago, but the company offering the free integration essentially stopped offering the free part. I'm currently grandfathered in to mail channels.
Fun fact, you can actually use the current send_email binding to send emails to verified emails in your account (but this announcement will make it possible to send emails to everyone)
You can also reply to incoming emails from what I know, you just cannot initiate any email directly to prevent the obvious abuse. I wonder how they plan to mitigate that apart from keeping the pricing sane.
I used to enjoy browsing PH and learn about all the cool projects people were building. And there were actually very good ideas -- at least in the early days of the community.
I even used to play a game that I've called PH-roulette: I'd open the top 10 or so products in separate tabs without reading their taglines. I then try to guess what they do based on the copy of landing page.
On most days, only one or 2 products had clear descriptions that are actually useful.
I started playing this game out of boredom but ended up learning a lot about what not to do while building my own landing pages.
"I'm the lead, and we are going to do it this way": avoid it for as long as you can, but do NOT hesitate to use it when it's the appropriate answer.
Take the time to listen to everyone and to form an educated decision. Explain your conclusion once, twice and even thrice. But sometimes teams can get caught in an endless futile discussion over details that don't matter for the stated goals.
In that case, it's *your duty* as the leader to play the dictator and impose order. "If you want to make everyone happy, don't be a leader. Sell ice-cream", Steve Jobs reportedly once said.
If it happens though, don't forget to re-establish trust with your team members and make sure they understand the circumstances that led you to act in that way.
This is a lesson I learned the hard way. When I was a first time manager I had the naive idea that I was going to build consensus for everything and get everyone to come to an agreement naturally.
It worked at first with a good team. Then later I inherited a fragment of another team with some older know-it-all engineers who thought everything modern was garbage and we should be doing everything like they did 25 years ago. I wasted too much time letting them stonewall everything while thinking we’d eventually reach a consensus.
Then at some point you realize you have to put your foot down and pick a direction after they’ve had a chance to state their position.
What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good.
That's not to say that consensus always works. But it does mean the group needs to understand the objections and make decisions the team can live with. The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the outcomes.
Sometimes there is time pressure or difficult people but the base assumption should be that people actually want to make the right decision, being difficult generally makes your life harder. Who would be responsible for executing on the decision and who would be responsible for the outcome? What are the consequences of strong arming the team into solutions they don't agree with?
Old engineers will say things that are hard learned lessons like "don't reinvent the wheel, when your thing is running on a system that comes with wheels". So, good solid advice that rookies will ignore, because of course they do. But sometimes old engineers will say things that are more of the quality of: "30 years ago went deep into this topic, discovered the truth and haven't updated my judgement since, despite the world having changed a lot".
The problem is that unless you really know things inside out or know the hard held opinions of your older collegue well, it can be hard to tell the two apart. In that case it only helps to talk about it in more detail and try to get to the root of where the judgement comes from. Then it could come to light that the warning to use PHP comes from a bad experience with PHP version <1.0 or that there is a number of bad experienced that are really useful for deciding the direction of a project.
In the end many decisions are about taste. And nothing is as good as a way to keep arguing than matters of taste. Weigh all the pros/cons and make a choice.
I'll second this. Unfortunately experience is a two-edged sword. I deal with a lot of old programmers and I continually hit the "fact" that was true in 1999 but is false today.
For example, I started in DOS (as did many older folk). Memory was severely constrained. So we developed habits to use memory (and disk space) very efficiently.
Like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field.
All those habits proved to be bad in the long run. And today memory (and disk space) are abundant. But these old habits are hard to break.
And that's before we talk about "modern" techniques, like version control etc.
Experience is great. I'm a fan. But all too often experience is also "there was a bug I windows 95, so that API call is unreliable ".
>many older folk...like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field. All those habits proved to be bad in the long run.
I'll bet you the people inventing these modern new architectures are among the more experienced engineers at the companies
who I would criticize by saying, we used to think it was a good idea to code around the limitations of old architectures and now we're accused of coding for PDP-11s and processors aren't PDP-11s any more. so what we should do now I'm told is code very specifically around the idiosyncracies of the new PDP-11,000's and that is what marks progress. Caches were invented to invisibly and silently make things faster, and that was a brilliant idea. Now new cache designers analyze what we used to do to insist we change how we code so they can cache what they want to cache not what we want to do, and all younger programmers talk about these days is coding for the cache (which itself is a cache of a cache of a cache). this is not progress, it's coding for the timing of the modern storage drum.
You can still obtain a ton of performance by minimizing the size of right things, processor caches are relatively small still. Stuff like the order of columns in a postgres database can still at worst multiply your table size
Yes, but we went from a time where these optimizations were absolutely unavoidable (so unavoidable that programmers would sacrifice any other thing for it) to one where the optimizations may be a nice to have, but for most organizations the maintainability of the code is much more crucial.
As mentioned before there are exceptions, like embedded programming, anything that needs to be finished within predictable time (game code, graphics, DSP code, etc). But even if you write a thing for a company website today I wouldn't dare to answer if making the code 10% less readable to make it use memory 10% less memory is a good trade off. Not that redability and memory use are necessarily mutually exclusive goals, but if you highly optimize code for one dimension, others will suffer at some point. And if you come from a generation where memory usage was king, it could be that you make these trade offs out of habit or principle despite them maybe no longer aligning with the goals of the project you're working on.
Anybosy who is good at their craft will choose how to deal with trade offs depending on the needs of the project and not based on remembered tradition.
With 20 years of experience in website development, I have led various site speed optimization teams. From my background, I pay particular attention to assets, JS profiling, and related aspects whenever I work on a web app. These practices are so ingrained that I perform them automatically and transparently, as they have been part of my process ever since.
The same thing might happen to these engineers when working on existing or new projects and writing C/C++ code; these optimizations will be part of their process.
I was born in the 90s so memory has been plenty for me during my programmers journey. Until I started doing more embedded signal peocessing stuff.
It is good to know how to use memory efficiently, even today. But it is also important to know that if you optimize for memory usage or speed you may be paying in another dimension. And in my experience a certain type of old programmer can have a total lack of awareness that e.g. in some cases readability, maintainability, ease of use for developers, display latency etc. can be dimensions that are priorized over another for really good reasons.
The admin equivalent of that is somebody who provisions the same hard disk space for a server today as they did in the 2000s and then have the machine run out of memory on every fourth kernel upgrade. It is good to only use the necessary resources, but not if you can't/won't handle the ugly consequences that may come with it.
It still has a cost though, which needs to be taken into account in many situations. At our company the cost of compute, RAM, and storage are some of the biggest ongoing concerns, which can make the difference between profitability and bankruptcy, and we’ve done a lot of work on it.
That would mean you're not on one page with the others about what the project is meant to achieve and what not.
E.g. let's say one library is more privacy friendly and the other allows more data collection, depending on the project both could be pro or con. I respect developers who value privacy, but if you don't know whether a program is meant to collect data by the point you discuss library choices that eindicates either bad project planning, bad communication or both.
> What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good.
I would say that they are pretty average.
First I am not sure what you mean by "know-it-all", specifically if this is a positive trait or not. Let's say that it is positive.
In that case age does not matter much because you can have extremely good practices that are simply outdated. Yes they work. Yes, they are stable. But they may not be adapted to the current needs.
So age is not a good differentiator for me.
Now, if you drop "older" I agree with you (with the assumption of a positive meaning for know-it-all)
>> The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the outcomes.
Disagree. This can be very bad, but the worst situation I had was a very experienced developer with poor social skills making decisions for the team without a complete understanding of the entire picture
You could learn from consent based decision making, a hallmark of sociocratic worker coops that is underrated and can be applied elsewhere.
Hierarchy and coercion isn't necessary for avoiding decision paralysis in organizations. It appears to be the practical route but has all sorts of harmful and counterproductive consequences.
I don’t think that is a practical framework for situations where people aren’t already very closely aligned.
What happens when a few people are very vocal (and firm) in opposition to basically every change? Having dissenting views is valuable, but not when they have veto power.
Additionally, I think that framework is vulnerable to what I refer to as “death by yes but” - when everyone is just piling on amendments and precursor conditions, oftentimes conflicting, that result in a decision taking months (maybe even years) to make or scuttle.
I’m basing these comments out of experience - one example is a workgroup/committee operating under a similar model that was completely unable to do anything due to decision paralysis. The committee grew significantly more effective when we reformed the decision making process to have a small group of owners to handle pitching and (potentially) implementing the decision, then had approval be a simple yes/no majority vote.
>> You could learn from consent based decision making, a hallmark of sociocratic worker coops that is underrated and can be applied elsewhere.
>> Hierarchy and coercion isn't necessary for avoiding decision paralysis in organizations.
> I don’t think that is a practical framework for situations where people aren’t already very closely aligned.
Putting aside the concept of Sociocracy for the purpose of discussing engineering team leadership philosophies, one which I have observed to be very effective when working with experts is Servant Leadership[0]. From the Wiki page:
A servant leader shares power, puts the needs of the
employees first and helps people develop and perform as
highly as possible. Instead of the people working to serve
the leader, the leader exists to serve the people.
While Servant Leadership[0] might initially raise concerns resembling the problems you rightly identify with a sociocratic approach, it has the benefits of peer collaboration combined with accountability of the decisions made by leadership.
Yes it only works when participants have a shared aim
In full sociocracy, it...
> honors the circle’s ability to freely make decisions within its domain. This is key for the organization to remain effective. But it comes at the cost of members not having “consent rights” to every decision the organization makes. Each member will only have those rights for the circles they are a part of.
So it's not necessary to allow people outside that working group to veto or require compulsory followup through objection
There's no perfect solution to organization, everything is a tradeoff. I've also been part of working groups (made of people whose job description is to manage the scope of changes they're proposing) where everyone and the workers impacted by the decisions are in agreement and no impact on cost etc., but the exec decides no change can be made due to personal preference despite disastrous consequence. Or where an exec who abstains from checking in on a working group's efforts nonetheless counters it with shifting and contradictory demands whenever it comes time to take action, requiring going back to the drawing board repeatedly until people simply give up or leave the organization. Or where the exec asks for more data for a proposal, and then doesn't evaluate the data once gathered, leaving no recourse but to give up or leave the organization. We all have stories like this. Hierarchical organizations are also susceptible to paralysis.
I've often taken inspiration from RFC 2418, "IETF Working Group Guidelines and Procedures" [1], a rare RFC that defines a human protocol ("rough consensus") rather than a technical one.
Interesting. For that to work, though, it has to be true consent, not "it's the boss's idea and I don't dare to object out loud".
But I guess, if that's the environment you're in, then you're stuck with autocratic leadership (no matter what label it claims for itself), and your only choice is to leave or not.
Right, and some people’s role is to organize people and orient the group’s efforts by taking in big-picture problems and outputting direction.
There’s rarely a single correct answer— lots of good solutions have trade-offs— but there are often various wrong answers. Do the best you can to avoid the wrong answers, and when you inevitably run into the business end of one of your trade-offs, take comfort in knowing the other good options probably also had trade-offs, and tell the smug know-it-alls to cram it.
People working effectively towards a non-optimal solution is far more useful than sitting around arguing about the best way to do it.
You can build consensus around the decision making process and build a culture where the outcome of that process is widely accepted. As long as people have the time and pathways to make their case and input, and understand there will be some verdict that may or may not align completely with their opinion. Then its just the decision makers duty to synthesize things in good faith but probably has bought themselves some leeway.
One thing I like to do with sr+ engineers who will feel burned by a decision - esp. those very publicly against it - is to lead with some sort of concession... maybe a project they expressed interest in, greenlight for a week to research some POC.
Whatever it is, it tends to be considerably less value to the business than the decision itself, but it directly acknowledges their discontent and allows them to get something out of the process besides platitudes, (perceived) public embarrassment, and frustration.
The know it all engs were probably right though and you just added the self imposed productivity, performance, and TCO tax that everyone else adds by default
It took a while to emerge but a couple years into my F50 gig we ran into a situation where we had a bus number if 3 in a domain, we all knew that solution A sounds good on paper but is a shitshow in practice, but the rest of the team was still enamored of it and our reasoned explanations just weren’t being persuasive enough.
The popular vote was going to load us up with little emergencies that were going to slow several divisions down and we ended up talking to the bosses and ignoring the vote.
In trying to smooth this over, I realized that the problem is that the people who would be dealing with the consequences of a decision wanted solution C and everyone else wanted solution A. And I think it’s something worth remembering for future indecisions, that the people with skin in the game need to be able to veto a popular vote. If you don’t want the project to lose momentum.
Generally on a large project you will have a bunch of leads all dealing with different domains, and they will reach quorum on major architectural decisions, particularly cross cutting concerns and interfaces between Conway’s Law modularizations. The boss only needs to break ties when a consensus does not emerge. And I mean NEEDS. Second worst boss I ever had refused to break ties and we had an even number of leads, so it happened half a dozen times. We wasted hours every month venting to each other about what we hated about him and one of the regular attendees just about wanted to murder him for that, and have us help him hide the body.
Steve Jobs was also known to lock teams in a room until they arrived at a common vision. It's a difficult task, to align everyone, but in my limited experience not doing it resulted in extremely inefficient execution. What's more, people feel belittled and rejected if you disregard their viewpoints. Sometimes you need to get things done regardless of what people feel or think, but you can't sustain that for a long time.
locking people in sure achieves at least one thing, but then so does adding two zeros. Jobs locked staff in, at Google when you a book meeting room, the wifi and lights cuts off at the end - a kill-switch approach [1].
personally, I think those hacks are cute and handy, but once you recruit well, reward and empower your staff, leading becomes much easier. At google, that approach probably helped more with their ESG policies than staff productivity. In Jobs' case, probably helped "him" stay focused rather than his staff, a meditation technique of sorts lol
Re: Juries. wasn't the main reason to prevent the world outside the court from influencing their decision?
Very good point. There’s a big difference between “everyone gets heard” and “everyone gets a veto.”
Breaking ties is part of the leader’s job.
Of course if every issue requires the leader to break the tie, then perhaps there’s either a management issue, and incentive issue, or people don’t understand the strategy.
In my opinion this advice is quite fatuous, because it skips over the actual difficult bit, which is figuring out what to do when you have a problem that can't simply be decided by the person directly responsible for the the work, either due to complexity/scale of the problem, or because that person is not capable of making the decision.
If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?
If they're not getting the same inputs to their decisions as you are, why are you hamstringing them?
And if they're not capable of understanding the inputs to their decisions, why are you keeping them around?
> If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?
This doesn’t seem realistic to me. Division of labor also implies division of decisions. Mature individuals and teams will acknowledge when there are decisions they’re not able to make, and will refer them to the relevant teams.
An obvious example of this is legal: it hardly ever makes sense to leave a legal decision to a software developer or development team. But similar logic can apply to product management decisions, customer success, security, etc.
How is that an example? Legal is just an input. A mature individual is going to heed the advice from legal, most certainly, but legal isn't making the final decision. Legal doesn't know anything about all of the other constraints, like customer need and technical need. If they did, they wouldn't be working as legal council, they'd be doing the job we're talking about.
So, we're right back at the previous comment:
- If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?
- If they're not getting the same inputs to their decisions as you are, why are you hamstringing them?
- And if they're not capable of understanding the inputs to their decisions, why are you keeping them around?
Make sure people understand why you're making the tradeoff you're making, and also make sure they know you're taking the fire for it if you were wrong and they were right, not them.
I like that a lot. My favourite leaders haven't sought out my opinions much, but they made their intentions and basis clear. If I wanted to change something in their plan, I could do the work of making an argument from their basis. Most people aren't going to do the work of actually making an argument, so they get brushed aside. The few people who do bother to make an argument are the ones with a lot of conviction and motivation toovercome the new obstacles.
100%. I worked for a brilliant lead, he had a team of excellent engineers. But he was stuck on the socratic method, determined to lead by asking thoughtful questions and letting us sort it out. Important discussions would go in circles a lot, frustratingly so. Sometimes you have to be the decision maker.
“If you want to make everyone happy, don't be a leader.”
This is the most important line. You shouldnt be afraid to hurt some peoples feelings (though not intentionally and as kindly as you can of course). Absolutely nothing will get done if you want everyone to be happy
> "I'm the lead, and we are going to do it this way": avoid it for as long as you can, but do NOT hesitate to use it when it's the appropriate answer.
Taking this approach with skilled people paid to think can easily be interpreted as being dictatorial and often stifles future contributions.
> Take the time to listen to everyone and to form an educated decision. Explain your conclusion once, twice and even thrice.
This implies a rigid hierarchical structure, one lacking collaboration. Again, this approach might work with assembly line workers but won't fly more than once or twice with people paid to solve problems.
> In that case, it's your duty as the leader to play the dictator and impose order.
And it will be soon your duty to find people to backfill those who have better opportunities to pursue.
> If it happens though, don't forget to re-establish trust with your team members and make sure they understand the circumstances that led you to act in that way.
There is no "re-establishing trust with your team" when this form of "leadership" is employed. Once trust is broken, the only employees who remain are those with no better options.
I've worked with engineers like this, who have a massive god-complex. If you think your job is to second guess your manager's knowledge and experience, why are you working under them? You should be working as a manager somewhere else. You are not a peer, you're part of a team reporting into a person that company has entrusted to lead the team.
> I've worked with engineers like this, who have a massive god-complex.
Championing collaboration in a team environment where members are employed for their skills is to acknowledge the value of those members. How you equate this to "a massive god-complex" is a mystery to me.
> If you think your job is to second guess your manager's knowledge and experience, why are you working under them?
Again, collaboration is not "second guessing." It is an effective technique used to identify and pursue an optimal approach given the information known at the time.
> You should be working as a manager somewhere else.
Don't "should" on me. "Should" in the bathroom and wash your hands afterward.
> You are not a peer, you're part of a team reporting into a person that company has entrusted to lead the team.
Management is a personnel role, not a subject matter expert role. Many excellent managers do not possess the skills or domain expertise of those they manage. The great managers I have had the pleasure to work with would freely admit this if asked.
That you imply an organization chart reflects the ability to make informed expert decisions based on where one resides in same confirms to me a myopic understanding of management in general, let alone "how to lead in a room full of experts."
The only thing that matters is - Have you personally implemented your ideas in the real world or not? I don't care much for theoretical mumbo jumbo. You keep doing your thing and I'll keep doing it my way that I know works. It is irrelevant what you can "confirm" about me and my views - what a pompous thing to say!
> The only thing that matters is - Have you personally implemented your ideas in the real world or not?
Yes.
And I have made the mistake of "being a dictator" early in my career, only to learn that collaboration and valuing team members yields success much more often than me unequivocally imposing my viewpoint due to reporting structure.
> It is irrelevant what you can "confirm" about me and my views - what a pompous thing to say!
If you have management philosophies which differ from the limited communications in this thread, then obviously I am unaware of them until and unless you decide to share them here. Until such time, all I can do is draw conclusions from what you have posted thus far.
As to "what a pompous thing to say!"
This is the second time in this thread you have projected a judgemental position regarding my prose. The first time can easily be rationalized as perhaps a reaction "in the moment" or a poor choice of words. Now that you have done so again, I have to surmise the origin resides in yourself.
Humans sometimes yearn for the leader to put their foot down.
The quiet ones may want the yapping voices silenced so progress can be made.
And sometimes the yapping ones get out ahead of their own skis and don't know a graceful way to back down so they're happyish to be closed down, even if they're primed to come back with an "I told you so" if the leader gets it wrong.
Yes, and there is one trick I’ve learned instead of explicitly pulling the ‘I’m the lead’ card (which is valid, but not always the best move).
Present the decision in terms of its consequences — consequences that fall on you as the leader, not on others. You want to make clear that the accountability for the outcome rest with you and that others are "safe".
What usually happens when I do this is that the team defers to me to make the decision cause they recognize my point.
That way, you preserve alignment and authority without eroding trust, because the team sees it’s not about wielding power, but about owning the consequences no one else should or can carry.
In my most recent role I only pulled rank twice in more than 3 years. Both times, reluctantly and deliberately. I agree you want to build a LOT of trust and legitimacy before you do this and you can still build concensus once you've dictated a direction or path. Lead, don't micro-manage.
Steve Jobs was an awful human being and people like him would say anything to justify their toxic behaviour. Quoting gim was the worst possible choice. You can be a leader and a decent human being. For example Gabe Newell, to name just one.
Apparently it advertises to browsers and other extensions that it has dark mode activated when it's actually not, which prevents them from applying the appropriate theme.
For some reason, nothing says "future" to me more than having tiny screens embedded where they're not absolutely needed.
When I grew up in the 90s and 00s, screens were definitely the most expensive part of any system they belonged to. And any gadget that came with its own screen attached to it was regarded as a delicacy only for the elite.
Living long enough to see "disposable" screens cheaper than literal candy getting attached everywhere makes me happy.
Can't wait to see Gemini-2.5 Pro-level LLMs embedded inside single post-it notes and thrown away like it's no big deal.
There were a few USB drives which had a display that showed how full they were, but they weren't popular, likely quite fragile to filesystem implementation details, and AFAIK have mostly disappeared now.
... I don't get why folks would want to use such ram sticks...
That said, I am very appreciative of my 'inline USB-C power draw monitor' from a standpoint of understanding what kind of draw a given device has (up to it's limit ofc)
Before I got them, I hadn’t ever considered that a variable amount of power could be drawn by a laptop while charging.
For example, right now my laptop is at 63% battery and currently charging. It’s drawing 36W at the moment. When the battery charge is lower, it’s drawing more power from the outlet, and the higher the battery charge is getting, the less power it’s drawing from the outlet.
> For example, right now my laptop is at 63% battery and currently charging. It’s drawing 36W at the moment. When the battery charge is lower, it’s drawing more power from the outlet, and the higher the battery charge is getting, the less power it’s drawing from the outlet.
This is because Li-Ion charging logic is known as "CC-CV", or constant current followed by constant voltage. You limit the charging current to some value (say 1A) until the cell attains the target voltage (almost always 4.2V, though some chargers limit it to 4.1V to prolong cell life), and then you hold it at that voltage until the current diminishes significantly (most chargers cut the cell off and indicate charge complete when the current draw drops to 10% of its max (during the CC phase) charge current, i.e. 100mA here).
Ages ago I measured how much power it took for the Start menu to open in Windows 7 on a Dell desktop that was fairly average at the time. In my somewhat crude measurement it was 20W for about 2 seconds.
Brilliant! Thanks for measuring this - I know it may be crude, but it’s also the best measurement I have ever heard of for this!
Assuming you like that kind of thing, maybe you can also test the power drain from displaying seconds in the taskbar in Windows 11. I know Raymond Chen posted an article about it, but I’d be interested whether you can spot a difference. If it really is on the order of 5 mW, then I assume you can’t detect it.
One of the downsides of only using a laptop is that you can’t see this level of detail because the battery acts as a buffer.
I like those monitors for finding weird, surprising (to me anyway) things - like when I charge my Framework laptop from a USB port on my work laptop (because I don’t have another power socket handy to plug them both into the wall) the Framework laptop draws twice as much power when it’s asleep as when it’s awake.
The opposite way around to what I need!
From memory, 5W when running (not enough to prevent the battery slowly draining), 10W when in standby.
I love my AMD framework, and I don't think my numbers are as terrible as yours (7-9 watts just chilling watts idle. However, the 'sleep' use is still, bad. I hunch it's a linux thing. I don't even bother, I just turn the thing off.
The analogy I always use is the filling a water bottle one. In the beginning when the bottle is empty you can go full power and fill it up with high pressure. At the end you need to reduce the pressure to not spill the water. I know it doesn’t work like this with batterie cells but close enough. I had the same aha moment when realizing this. It’s one of the things no one normally thinks about in a world where everything is a given.
At some point your thumbs wouldn't activate the pads so you had to use your thumbnails and then it was just a matter of time before the tester strip quit working.
It's interesting that he speaks of them as something very old, but such batteries were still widely available in Europe not too long ago. I have a pack of Duracell PowerCheck AAA batteries made in Belgium and labeled good until 03/2029, which suggests a manufacturing date of 2019.
Yeah, I hope they put displays on more things. The trends are weird though, since some things that used to have displays no longer have them; you have to use the app on your phone instead...
I wonder if the previous generation felt that way about the little unlit LCDs that used to be in everything (although, I bet they were more than $2 adjusted for inflation).
My first "job" between school and university was to assemble a bunch of keyboards for banking terminals. They used configurable key caps in that a printed sheet was snapped under a transparent keycap cover. I suppose I must have been working on a short production run for a small bank or a trial project, that didn't merit screen printing the keys.
As I worked through countless of those keyboards I mused that what it needed was a little screen on each keycap, so I could just do my job using software.
I think they’d be functionally useless for my daily driver, but a keyboard that shows contextual hot keys to an app I’m learning (photoshop, blender, etc) would be a game changer.
I want them in arcade buttons to show the mapping for the currently playing emulator / game. You can get circular 0.71 inch LCD screens for under $1.50 (160x160) - which will fit all sizes of arcade buttons, but for some reason no one built this yet... :)
> A central premise of immunity debt is that for many infectious diseases, repeat infections are milder than the first infection.
This is also the fundamental, well understood, mechanism of vaccines and herd immunity [1]: "Immunological memory" [2]. I think that sentence is very irresponsible.
Writing this, I just realized that even at work, we only have a single monitor. And it's stored on a shelf not even plugged.
reply