You are right. Most do heat pumps with mini splits for each zone. However, ducted houses can certainly use heat pumps with an air handler. Typically this translates to heat pump replaced outdoor condenser (ac unit)and the air handler replaces the indoor furnace.
Lock-in is another way to say "bespoke product offering". Sometimes solving the problem a cloud provider service exposes is not worth it. This locks you in for the same reasons that a specific restaurant locks you in because its their recipe.
I'd counter that past a certain scale, certainly the scale of a firm that used to & could run its own datacenter.. it's probably your responsibility to not use those services.
Sure it's easier, but if you decide feature X requires AWS service Y that has no GCP/Azure/ORCL equivalent.. it seems unwise.
Just from a business perspective, you are making yourself hostage to a vendor on pricing.
If you're some startup trying to find traction, or a small shop with an IT department of 5.. then by all means, use whatever cloud and get locked in for now.
But if you are a big bank, car maker, whatever.. it seems grossly irresponsible.
On the east coast we are already approaching an entire business day being down today. Gonna need a decade without an outage to get all those 9s back.
And not to be catastrophic but.. what if AWS had an outage like this that lasted.. 3 days? A week?
The fact that the industry collectively shrugs our shoulders and allows increasing amounts of our tech stacks to be single-vendor hostage is crazy.
> I'd counter that past a certain scale, certainly the scale of a firm that used to & could run its own datacenter.. it's probably your responsibility to not use those services.
It's actually probably not your responsibility, it's the responsibility of some leader 5 levels up who has his head in the clouds (literally).
It's a hard problem to connect practical experience and perspectives with high-level decision-making past a certain scale.
> The fact that the industry collectively shrugs our shoulders and allows increasing amounts of our tech stacks to be single-vendor hostage is crazy.
Well, nobody is going to get blamed for this one except people at Amazon. Socially, this is treated as as a tornado. You have to be certain that you can beat AWS in terms of reliability for doing anything about this to be good for your career.
In 20+ years in the industry, all my biggest outages have been AWS... and they seem to be happening annually.
Most of my on-prem days, you had more frequent but smaller failures of a database, caching service, task runner, storage, message bus, DNS, whatever.. but not all at once. Depending on how entrenched your organization is, some of these AWS outages are like having a full datacenter power down.
Might as well just log off for the day and hope for better in the morning. That assumes you could login, which some of my ex-US colleagues could not for half the day, despite our desktops being on-prem. Someone forgot about the AWS 2FA dependency..
As a former engineer who recently transitioned to management, this is precisely how engineers who are competent are perceived as underachieving. Focus on the right problems, put side quests on the back burner.
But how do you know what the management perception is of whiat is currently considered to be 'the right problem' vs 'side-quest'? To what extent is that subjective and manipulable? Or that everyone in the management chain is fighting to maximize their perceived contribution to the former and minize their perceived contribution to the latter?
Without knowing the context, it's impossible to tell whether the key word in your sentence is 'perceived' or 'achieving' or 'focus'. Or what set of people shape the perceptions. Or on what KPI. Or what if there aren't even clear metrics. Most engineers like working on designing things, not executive palace coups.
(Corollary: have you never seen a group or entire dept get sidelined by being assigned something that they're officially told is important but at some point is publicly/secretly determined not to be, at some murky point up their management chain? What happens when the Director, VP, CXO are changed, perhaps multiple times, in a project?)
> But how do you know what the management perception is of whiat is currently considered to be 'the right problem' vs 'side-quest'?
You ask.
A large number of the problems I helped people work through while mentoring came down to engineers get stuck in their own head instead of communicating.
Whenever it's not clear, you communicate. Many companies have this as a daily update ritual in standup, but some engineers treat standup like a game where they have to say the right thing to get it over with as quickly as possible before going back to their computer and forgetting what they said they were going to work on.
If ambiguity persists, it's a good idea to write a short e-mail to your manager saying you're working on X instead of Y or Z because you think that's what's best, but then finish by asking them to let you know quickly if you got it wrong.
> Corollary: have you never seen a group or entire dept get sidelined by being assigned something that they're officially told is important but at some point is publicly/secretly determined not to be
No, I have never worked at a company so dysfunctional that management will make secret decisions but forget to inform the company, or make public decisions and an entire department will ignore them.
I don't get it. What's the incentive for anyone to do this?
Though I have worked with some people who would go off on their own tangents, then when the consequences caught up with them they'd concoct excuses about how it was never communicated to them (despite us pointing to records in Slack where they acknowledged) or elaborate conspiracies about management coming up with secret changes or something.
You don't have to do anything. But as you say, they are the one in the position of power. If you are working on some side quest they don't see as valuable, it may not end well for you. Doubly so if you are shirking what they see as a high value task for your side quest.
It's not about what is right or who "should" do what, it's about securing the best outcome by making sure you and your manager have the same understanding, even if your manager isn't doing a good job of making sure you have the same understanding. (Also known as "managing upwards.")
Obviously the context is after you and other people have asked; multiple times. You should interpret my comment with that reasonable preamble. And obviously as you say when people are being ambiguous or not communicating well, you memo what was communicated in writing. But that doesn't cure all organizational ills, not by a country mile.
It's nice if in your sample size you've personally only ever come across management chains that were trustworthy, competent and aligned. It's nice if you've only ever seen one unambiguous flow of truthful information from the bottom to the top and vice versa, and everyone's aligned to cooperate. But the alternatives abound.
I've seen (or been told of) directors battling other directors on organizational priorities, senior managers quietly undermining and deposing VPs so they could take their jobs, EVPs of sales selling capabilities that their own engineering had been telling them could never ship, the sales-side of an organization having a totally different roadmap than engineering and feeding it to a (nontechnical) CEO who couldn't tell which was accurate; CEOs putting out press releases about fictitious component their engineering was telling them they would not be available. Managers cheerily suppressing showstopper issue reports to send "mostly green/96% done"-type status reports up the pipe, on a project they knew to be doomed, before they completed their company-sponsored MBA then promptly jumped ship to a rival, and the company failed. Board members hyping underwater stock internally, only to quietly step down and immediately dump all their stock now they were no longer designated as privileged insiders. (Remember: once you go public, there are disclosure requirements and possibly shareholder class-actions, so even when something's universally known internally to be an issue, often executives can't acknowledge that, even internally (think "audit trail"); although you can infer a lot from their actions.)
Also you're presumably aware of some company cultures where internal secrecy and internal competition are fostered, pitting departments against each other (or at absolute minimum, where cooperation between departments is heavily discouraged, or punished). Or, in the middle of a product development cycle suddenly launching a "partner collaboration" or "strategic acquisition", where that is misaligned or competes with internal groups. Fear, intentional ambiguity, conflicting priorities as a management tool. Often this stuff is indirect evidence of conflicts at VP-level or higher; sometimes it's culture or force-of-habit.
Nobody said "forget" to inform the company or "departments ignoring clear and unambiguous directives". I implied misinforming or misleading groups/depts, or maintaining strategic ambiguity about what priorities were.
> What's the incentive for anyone to do this?
All of the above happen regularly, and it's pretty obvious what size and structure or organizations, and what individual metrics for compensation, and in particular when metrics are intentionally designed to be in conflict. For example, in a large company once you define separate "business units", people are overtly now working to differing metrics.
"conspiracies" and "go off on tangents" is a pretty disparaging way to misinterpret my question. You've never heard of any of the above ever being intentionally deployed? And "dysfunctional" might be our shared opinion, but I've heard from board members that passionately believe companies should be incentivized like that.
There's a reason Software Anti-Patterns (both technical and management) were recognized to exist several decades ago. [0] I think you're merely saying you haven't personally encountered them much.
For sure there are some engineers who treat standup like an annoying interruption to real work, or can't be articulate; equally there are scrum meetings where people play points hero or points olympics in inflating their perceived velocity. I've seen some adept operators nurse a weak spot in their part of the product so it could get closed then quickly reopened multiple times for multiple different customers, making them look great, but no mention of refactoring or adding testcases, or explanations of whether the thing was incorrectly closed or underestimated previously. Agile is only as good as the people overseeing it and measuring; it's easily gamed.
Communication does not happen merely because you mandate a 15-minute daily(/weekly) team meeting and tell people to do it; it only happens when people's official or unofficial incentives are generally roughly aligned to facilitate it. It's much easier to do that in a 10-person shop all working on the same product than 10,000 people, multiple teams, multisite, multiple products, dendritic orgchart, etc. You haven't really focused on the "managing perceptions" aspect of my question at all. There are certain breeds of middle-manager whose careers thrive on going into problem depts of large companies and cultivating the perception of them as firefighters/powerpoint-warriors, whether that's decoupled from reality or not, before they move on before the success/fail outcome becomes apparent. Again, misaligned incentives, and works best at the interface above which management stops being technical. If you're inside the dept in question, you can actually see how much of the perceived performance is objective verifiable fact vs managed perception. Or to put it another way to you, you've never seen people who are roughly as good as each other, yet one is more adept at managing perceptions?
It helps us gauge your personal experience if you tell us what size of team and organization and company stage (early starup/late-stage startup/small/large public company/etc.) you're anecdotally referring to.
> But how do you know what the management perception is of whiat is currently considered to be 'the right problem'
Ask! Literally. But also listen.
Many people in management will repeat over and over that feature X is the thing they wake up thinking about, even though feature Y is important to the PM or director or whatever. Especially if you’re young enough that promotions and performance reviewed are really important for career growth, work on X not Y.
If your manager doesn’t start every meeting with some passive remark that project X is consuming their time, ask them what is important. Ask them what project they’re worried about.
Example:
“Hey Boss, I’ve been working on ProjY, but I also have tasks from ProjX pulled into this sprint. Which one is a bigger priority for the team, because I have 10 days of tasks, but only 1 week left in the sprint?”
… “hi boss, a week ago you told me to prioritize finishing X and not Y. Should I just allocate all of this sprint to the next set of tasks for X?”
… “hi boss. It’s me again asking this question every week “
If you want a good performance review/promotion/etc, usually that starts with your direct manager, so do what they think is important and ignore the rest. You need their trust first, so get it by working on their priorities. With their trust, you can get flashier or more fun work, or you can get them to trust you when you suggest alternative priorities, and you can earn the gossip/news they hear in management meetings from up the chain.
Your corollary is just rage-bait FUD or dysfunctional behavior. Any you can’t control it anyways so ignore it and focus on what matters that you can control. If your CXO doesn’t like what you’re working on, but your manager does, pick your manager, they actually write your performance review.
Most people don't know they can "install" a website on their phone, let alone that it allows that website to act like an app.
Discoverability of PWAs is quite bad. I'd love them to become more popular, but attempted solutions range from "user manually needs to hit the install button in a menu" to banners capable of saying "install freewhatsappupdate.xyz for exclusive whatsapp deals"/"click install to verify you're human".
Microsoft actually tried to bring more attention to web apps by adding them to their app store, but nobody uses the MS app store.
Somewhat roundabout, but WEI can make it so you need to have an allowed device-OS-browser combo for important services like banking. The device can then make it impossible to install another OS, and the OS can make it impossible to install another browser. Then the browser (or the OS) just receives blacklists (and possibly eventually whitelists after everything is entirely corporate captured) from Google/Microsoft/Apple.
Sure AI can build cute POCs. Will it build scaled solutions, not this year. The amount of ignorance in this post is precisely why the industry is so rattled. Gen AI tools are great, they are not making people orders of magnitude more productive.
If one is expecting Lovable to create a production app by just giving a few prompts, that obviously is not going to happen, not now and most probably for a long time.
However, if you use Claude Code or one of the proper IDEs, you can definitely guide it step by step and build production quality code, actually code that may even be better than most software engineers out there.
Moreover, these tools allow you to take your proficiency in software dev and specific languages/frameworks to other languages/frameworks without being an expert in them, and that I think is a huge win in itself.
I work in big tech as a senior engineer. I’m aware of what’s out there and none of it is solving problems in a way that’s replacing swathes of engineers anytime soon.
It may be an excuse to layoff but it’s not ramping up velocity in ways that PR is making it seem to non tech literate.
I never said anything about swathes of engineers, merely that it is possible to build production quality stuff.
From my experience, these are better suited at the moment for small teams and new projects. It’s unclear to me how they’ll work in large team/massive legacy code situations. Teams will have to experiment and come up with processes that work. IMHO anyway.
We’ve been in business 15 years. These aren’t POCs. Even at say 20% productivity boost I feel way ahead to give devs 9 day fortnights and soon hopefully 4 day weeks.
how is it both a bootstrapped company slow to hiring devs (due to AI) and also a company that's been in business 15 years? if you were going to hire devs to scale out, you would've done it 10 years ago?
Normally as we add enterprise customers we have to dedicate more dev resource keeping them happy. But since Claude code and now codex we have not felt that feeling of not being on top
of the work. Thus not feeling the need to hire more devs.
By having a population who reads a clickbait headline, doesn't read the article, doesn't do any further study, and then propagates the falsehood and moves on to the next one.
It would be analogous to having to double check the IDE added the lines of code I actually typed. That’s not a great productivity boost, it’s a toy still in many ways.
