Aceticon

In my experience the hard part is to make it have low enough consumption to be ableable to run on batteries without draining them too quickly.

You'll probably have to ditch the one or more of the boards and replace them with the just the components (in the case of the GSM one, the module) which can be a bit complex to begin with if the board is generating its own voltage for the components and you don't know how to do it yet (look into voltage boost converters - probably needed for the GSM module - and buck converters - the most efficient way to get 3.3V from a LiPo battery - as you can find plenty of chips that do most of the work for you)

That said the ESP32 is very easy to run on its own once you have the 3.3V it needs - if I remember it correctly you need all of a single 10k Ohm external resistor to make sure RESET is pulled up - and you can still program it with the Arduino framework.

Once you're ready try designing your own circuit board with something like Kicad and have it done in one of the cheap Chinese retail circuit board makers like JLCPCB.

Most people don't actually know what they need until the see it, and the only ones who might are those who already have a process in place (hence know it in detail) and just want it or parts of it automated.

People often do think they know what they want, but it's a very general and fuzzy view, with little in the way of details and which seldom considers what should happen outside the most thread path of their process (i.e. things like error situations such as "what if somebody enters the wrong data in this form" or after the fact responsibility tracing in the form of usage logs and reports).

It is actually a bit of an art to tease the details of the requirement from the stakeholders in a consistent and thorough way and also spot and get requirements for those "outside the main process path" elements and, frankly, in my career I've met very few people - even amongst business analysts - who are actually good at it.

That said, what maybe the main advantage of Agile when done properly (with proper use cases and the actual end users trying the implementation of those requirements out) is exactly that it's an interactive process to refine the requirements by cycling back and forth between requirements gathering, feature development and result evaluation to fill in missing details and tease out further requirements. IMHO, this is actually were Agile shines the most when compared to Waterfall, but as I said you need to do the requirements gathering and results evaluation parts of Agile (so the parts involving interacting with actual users bot upfront in making use cases and at the end of the cycle in evaluating the fitness for what they need of what was implemented) to get those gains, and most "Agile" teams out there seem to only do the fashionable parts of Agile like the "standup meeting" which aren't what makes it most valuable as a process.

Well, seniority helps on the deadlines front: you can spot managers trying to force too short deadlines on you a mile away and throw it back at them ("I'm am the specialist, so I'm the one who knows best how long it will take") and if they just try and impose deadlines you can bluntly state "that isn't possible" and if they somehow have the authority to push them you make sure everybody (especially other managers, ideally the managers above them) knows that you've informed them upfront that such deadlines were impossible so when it inevitably fails, said manager can't shove the blame your way.

As for obtaining things from other teams, that's a two part thing:

• First make it painfully obvious in your estimates that a dependency on something from an outside teams exists. When inquired about progress, constantly point out that it will only happen "if that team provides us what we need to progress". Keep reminding people that those deliverables are a conditional for yours - "they're late our project is late".
• Second, start pushing them for delivering to you what you need well before you need it. It's there, in your planning, so you know you need it and have some idea of when. The bigger the project the earlier you start pestering them. Persist on asking them for it, escalate to upper management if no movement is visible on their side. Make sure the groundwork is set so that if they're late they get the blame on project deadlines being missed. It depends on the country culture but generally most people aren't really impeccable professionals at time and priority management (and yeah, that includes managers) and tend to prioritize addressing "what's burning harder" in their pile, hence why you need to start pestering them early, do it often and with more urgency the closer it gets to the point you need it (to make sure it's perceive as an urgent need and rises to the top of their priority pile) and make sure the groundwork is set for them to be blame if your own deadline is missed because they were late and, more importantly, that THEY know they will get the blame (this generally at mid/upper manager level), so that from their point of view it's "burning" (i.e. they'll suffer if that doesn't get picked up on time)

Of course, all this requires competent management since they're the ones supposed to do it and if your managers are trying to impose deadlines on you or using slimy trickery to get people to commit to shorter deadlines, they're NOT competent managers - that kind of shit invariably yields death marches and bug-riddled results that in the mid and long term end up wasting far more time that it was shave by those shorter deadlines.

Kinda sad that one has to play such games. Welcome to Mankind.

I would describe it as "insufficiently thinking about and researching the problems space".

From what I've seen that's very common because developers have a tendency to want to be hands-on rather than merely researching, myself include.

Even for the sake of figuring out inconsistent requirements or even just big gaps in the requirements, it's a good idea to really think about it and cross check things.

Personally, the more I advanced in my career and the more complex and larger problems I had to tackle, the bigger the fraction of preparation time vs the fraction of coding time and I believe most very senior devs have the same experience.

I think you're confusing doing analysis before coding with doing all analysis before coding.

If you do Agile properly (so including Use Cases with user prioritization and User feedback - so the whole system, not just doing the fashionable bits like stand up meetings and then claiming "we do Agile development") you do analysis before development as part of evaluating how long it will take to implement the requirements contained in each Use Case. In fact this part of Agile actually pushes people to properly think through the problem - i.e. do the fucking analysis - before they start coding, just in bit-sized easy to endure blocks.

Further, in determining which Use Cases depend on which Use Cases you're doing a form of overall, system-level analysis.

Also you definitelly need some level of overall upfront analysis no matter what: have a go at developing a mission critical high performance system on top of a gigantic dataset by taking a purist "we only look at uses cases individually and ignore the system-level overview" approach (thus, ignoring the general project technical needs that are derived from the size of the data, data integrity and performance requirements) and let me know how well it goes when half way down the project you figure out your system architecture of a single application instance with a database that can't handle distributed transactions can't actually deliver on those requirements.

You can refactor code and low level design in a reasonable amount of time, but refactoring system level design is a whole different story.

Of course, in my experience only a handful of shops out there do proper Agile for large projects: most just do the kiddie version - follow the herd by doing famous "agile practices" without actually understanding the process, how it all fits in it and which business and development environments is it appropriate to use in and which it is not.

I could write a fucking treatise about people thinking they're "doing Agile" whilst in fact they're just doing a Theatre Of Agile were all they do is play at it by acting the most famous bits.

You can have airflow friendly design without the flat single color body, plastic interiors and a tablet on a plastic pedestal.

Agreed that the whole SUV trend was a massive step back in so many ways, but being in Europe I'm not even comparing Tesla's design with SUVs, I'm comparing it with other cars in the same category since they are still most of the cars in Europe.

Even something like a Mini Cooper EV looks downright daring next to the stale styling of Tesla's offering.

The cars that I notice on the roads which leave me with the same overall impression in terms of looks as Teslas (minus the ugly tablet on a plastic pedestal look) are BYDs, which are way cheaper.

At this point in time Teslas stand out from the rest because they look like a mildly tweaked (mainly the higher back, inset door handles and big fat tablet in the middle of the dashboard) late 90s sedan or roadster design, because late 90s vehicles of these categories are the core visual styles they copied and tweaked in an attempt to make them look futuristic, a style which they haven't changed since.

(Maybe that stuff was very different from the common car in the roads in North America, but it wasn't in Europe).

The novelty value of inset door handles is gone, plastic interiors and big fat mid-dashboard tablets on a pedestal look ugly and dated, and the core car body design style just looks like your parent's car back in the day.

Tesla are kinda like those old Sci-Fi Movies from before flat screens and computer graphical user interfaces whose idea of futurism were fancier cathode tube screens and showing fast moving green screen text. The thing is, only beloved Sci-Fi filmic universes with cult followings (or alternative universe ones, like steampunk) still keep those visuals in any new movies, and Musk has been busy blowing up what little cult following Tesla had (which itself was already limited because, unlike Apple, Tesla never stood for quality and that following was mainly linked his own personal cult and perceptions of higher eco-friendliness than the rest, both now gone).

Yeah, but they already live abroad because they can (given how the Law is made, they can use it to avoid existing taxes) and they prefer the quality of life there.

My point is that those who don't do it already, are were they are still rather than living in Monaco to avoid existing taxation because they would rather live there than in Monaco, so their threats of leaving if taxes go up are seldom true. Further, if taxation is based on asset ownership and asset location it doesn't mater were those individuals live, it maters were their assets are: whether they live in Monaco or not, they'll be paying the same for, say, realestate they own in the UK, since that's something they can't take it with them, so they'll have to divest from those assets by which point they won't be profiting from the conditions in the UK that make those assets be so profitable for them.

Situations like Lewis Hamilton's or Taylor Swift's - people who makes their money mainly from their own work, though they also ride legal weaknesses that let them avoid being taxed on were they actually operate and/or sales were the sale happens (in this case by not paying tax were they play concerts or do races) - are actually unusual as high net worth individuals: most of the very wealthy make their money from the income of asset ownership, and assets have a physical location (even IP), at the very least some kind of national registar somewhere that certifies that they own those assets, so governments that genuinelly want to tax most of the rich who are not paying fairly into the common pot were they derive their gains (i.e. at the very least by making those assets so profitable to own) just have to tax them via the assets rather than via residence.

On the people side, the ones who would do it are already doing it: for example rich people who go live in Monaco 6 months a year to have residence there. The one's who aren't doing it and simply bitch and moan about it seldom tend to start doing it because they prefer the lifestyle of being were they are rather than the "live in your yacht of the coast of Monaco".

As for businesses, they only ever do it when they can still keep operating with the same advantages in their original markets whilst paying all taxes elsewhere that is cheaper. In regimes were taxation isn't actually based on "place of sale" but instead on HQ location, the move their HQs to reduce the tax they pay but they don't actually move their businesses. Such moves indicate that tax legislation is actually not taxing the doing business (i.e. their actual selling) but something else and thus need fixing.

It's incredibly rare for a business to actually stop selling altogether in a country merely for tax reasons - instead what you see is them trying to use accounting loopholes to move their tax residence elsewhere.

Who says that's not her true opinion?

She did very openly get close to the Cheney familiy during her presidential campaign, so she might very well think that according to her own values he had done nothing wrong.

It seems to me that one of the core problems of the Democrat Party leadership which has led to their candidate being defeated once again by none other than Donald "Sex Offender" Trump, is exactly that their values are pretty much compatible with Cheney's.

But, but, but ... no matter the politics of their candidate clicking their heels and saying the magic words "vote us to stop the other guy" has always worked as their main electoral strategy.

Obviously with such a magical and infallible electoral strategy, this election loss can only be explained by there being something wrong with the voters themselves as that strategy makes the quality and politics of the candidate be irrelevant!

IMHO, most people's time usage perception tends to be heavilly skewed toward weighing higher the time taken in the main task - say, creating the code of a program - rather than the secondary (but, none the less, required before completion) tasks like fixing the code.

Notice how so many coders won't do the proper level of analysis and preparation before actually starting coding - they want to feel like they're "doing the work" which for them is the coding part, whilst the analysis doesn't feel like "doing the work" for a dev, so they prematurelly dive into coding and end up screwed with things like going down a non-viable implementation route or missing in the implementation some important requirement detail with huge implications on the rest that would have been detected during analysis.

(I also think that's the reason why even without AI people will do stupid "time savers" in the main task like using short variable names that then screw them in secondary tasks like bug-fixing or adding new requirements to the program later because it makes it far harder to figure out what the code is doing)

AI speeds up what people feel is the main task - creating the code - but that's de facto more than offset by time lost on supposedly secondary work that doesn't feel as much as "doing the work" so doesn't get counted the same.

This is why when it actually gets measured independently and properly by people who aren't just trusting their own feeling of "how long did it took" (or people who, thanks to experience, actually do properly measure the total time taken including in support activities, rather than just trusting their own subjective perception) it turns out that, at least in software development, AI actually slightly reduces productivity.