Dragony's comments

I actually worked on an App for a company that made home appliances. Originally they made everything local, so direct App to Washing machine communication. They had a really hard time with that approach for a number of reasons.

The first, and most obvious, reason is that getting your phone and (all) your appliances on the same network is non-trivial. Especially for a novice user. Sometimes the washing machine is in the basement and can't connect to your WiFi. Or maybe you're simply outside your house in your car and can't connect to your local network. The cloud approach solves this.

The other, not so obvious reason, is that the manufacturer made a ton of devices. Some of them a decade old, with very rudimentary interfaces. Originally the App had to handle special cases and workarounds for dozens of devices. This became a problem once they tried to port it to multiple platforms. For Android and iPhone they started with a shared C++ library. But that quickly became a problem, once they wanted to interface with popular home network and automation solutions.

To solve all this they decided to build a cloud API that would resolve all these problems in one go. A single, unified API with a modern HTTP interface and available via the internet. That solves the workaround and compatability issues by having a single abstraction layer (instead of one per app). It solves the "on the go" problem when you're not in you local wifi. It enables you to control devices outside your home network in a true IoT sense.

I totally agree with you that, if you're not in an urban environment with good internet and cell coverage, the advantages dwindle away. Also, of course, there is the privacy concern that is very real. At the end of the day the cloud solution is selected for the same reason companies select Electron. It saves development time and is very easy for the average end user to use. At the expense of performance and privacy.

Many things in this article, especially about the problems with the Data Science role, resonate with me (low value work with low expectations for quality). Funny thing is I have never worked in Data Science. Rather I've worked in Software Development. The summary at the bottom about Data engineering seems like the dream job to me. But I don't think it's because I'm interested in doing Data engineering specifically. I think it's because doing things that actually have an impact day to day is fullfilling. The last job I had totally lost me after ignoring security problems in favor of surface level things like updating CTA labels or similar. Have other Software Devs had this experience?

Sadly there are a number of functions in the PHP standard library that literally never can return true. Often they return a resource or false, for example. In those cases the `false` type is more accurate than boolean. That's the reason for the distinction.

Test

Generally speaking software makes things faster, not better. Good software for a bad process will simply expedite problems.

I've thought for a while that this kind of change for the sake of change is fuelled by the number of employees in the companies involved. The ratio of developers you need to build an application vs maintaining one is huge. That creates an incentive for companies to keep building.

Out of the perspective of Agencies (Outsourcing) each working developers generates revenue. Product companies can choose to either keep their employees and keep building, or simply let a huge chunk of them go. Letting a huge number of people go (mass layoffs) is generally seen as a bad thing. So they go the other route. Keep the employees around and have them working - building new stuff.

In general estimates are risk assessments. With that in mind, I think the way to go about estimates depends on the experience level of the indivual or team. The best estimates are not only a number (or a t-shirt size), they also include a list of possible things that can go wrong (either as an internal dialog or, in the best case, written down as part of the estimation).

There are many methods to get this assessment. These are the ones I have used:

* Basic level: Write down everything that needs to be done and assign a time estimate (in hours, otherwise break down further)

* Intermediate level: Write down everything that needs to be done and assign a range of time in days (from best to worst case scenario)

* Expert level: Use an abstract scale (like the fibonacci sequence, T-shirt sizes, etc)

* "We've been doing this together for 20 years" level: Can it be done in XY time? Yes or No answers only.

In each of these levels the specific time it will take to complete the task becomes less and less specific. The reasons to keep it specific, are a) to learn how to estimate well and b) to keep people accountable. Reasons to keep it unspecific are that a) it's impossible to get a correct number for a task you've never done before, thus b) it's a waste of time to try and make an estimate accurate.

The value of all these estimation techniques is to find out where the most risk lies (usually there where the most unknowns / complexity lies). If you then don't follow up on those risks by checking in with the team, the estimation becomes useless. If you manage these risks well, you should at the very least have consistent estimates. Even if their real-time equivilant is off, it should be off by a consistent amount.

Most important of all though: Estimatation is a learned skill and not inherent to anybody (developers or managers). It takes time and practice to get going accurately.

Think of it this way: It's a social contract between the company and the employee that you will spend your time on something valuable to both the company and you. In larger organisations it can also help to answer the question "What is your team working on?".

I have in fact experienced employees (peers) that will simply slack off and say they "weren't told what to do" when asked. It's infuriating to work with those kind of people. Those have been exceptions though.

From my experience as participant in these kind of systems, this is what I think:

These systems have the goal to create buy-in from the employee to perform at a certain level. Since you create these goals yourself there are little excuses why you can't reach them. It creates an incentive for the employee to work hard all year long and lessens the burden on the company to continuously check if you're being productive.

I guess another way of saying it is: You define what you're getting paid for year over year. What value you're providing for the company.

SEEKING WORK | Switzerland | Remote Technical Project Manager

Seeking part-time or contract work as project manager, project consultant or agile coach.

I am a technical project manager with 15+ years experience of building applications. During that time I was a pm, as well as a developer. That lets me unterstand and communicate where other managers might fall short.

My experience covers Agile Projects (not only scrum), classic waterfall projects and maintenance of existing applications.

I am looking to support projects as a facilitator, consultant or traditional project manager.

An extra fascination of mine is personal time management and efficiency. If you're interested in that kind if thing, feel free to contact me. Even if it doesn't directly have anything to do with a job :-)

Contact: https://ma.ttias.ch/about.html

This is something I made as entertainment for my significant other: https://wasd.ch/keyboard/

I had some spare time and decided to code something small that would be a fun timewaster with some inside jokes.