bhldev's comments

I value experience a lot, over almost anything.

What you mention is very dangerous to the data. Take the medical app example. Suppose there's an app to update a chart that doctors carry around. Suppose there's five doctors and/or nurses working on the patient. Whose prescription or orders do you take? On top of that it gets worse -- there might be dependencies between the orders, orders might be to countermand other orders or in response to others which may or may not exist. It is not a problem that any algorithm or programming can solve, because the whole point is to take the experience and skill of the doctors which is being blindly ignored for some process that the doctors may or may not be aware of who submit the information. Similar problems could appear for any of the examples you mentioned if you dug hard enough.

As for the submission you can simply ban submission unless you have an active Internet connection. 737 Max is also "real world experience" Boeing panicked at Airbus and instead of going through a 10 year design and 10 billion dollar process for a plane they surrendered to market realities at the cost of lives. The fact that "enterprise" has onerous business requirements or even legal requirements demanding technical sacrifice doesn't make it any less technically wrong. If asked to make a sync on the client side I would make it as simple and straightforward as possible and assume nothing.

I suppose so long as it doesn't cost lives or ruins people I don't particularly care if you value handling data on the client in this way as a qualification for "enterprise" mobile developer. As long as it's "good enough" to meet the requirement, great. But it doesn't mean I like it, and it doesn't mean one should ignore technical flaws. Unless it's ACID you don't guarantee anything it's just a feel good (and possibly done in a much simpler way). For all the scenarios you mentioned I can mention another half dozen scenarios or even a very simple one, one person with same seniority making exactly the same change to the same record. Then your system tosses one or the other or even merges them -- in other words you dive into expert systems, NOT anything to do with "syncing".

Experience is important but there's a theoretical foundation to everything and it's wrong to expect an offline node in a distributed network to act as a source of truth for any period of time. Sorry.

It's not an easy problem. It's a database concurrency issue and well beyond the skillset of most mobile devs. Database isn't even a required course for a compsci degree it's usually an elective.

My point is the problem you think you solved, you didn't and it will break under dozens of scenarios. Maybe the clients are happy and they think it works but you just haven't encountered the case where data goes missing or overwritten.

In other words what I am saying is it is wrong and hard to know it is wrong unless you directly attack it. The word "enterprise" is an euphemism for low cost and potentially low quality. It's a buzzword. I wouldn't take an Enterprise mobile developer over a B2C mobile developer just because of the word enterprise.

Not everything in the world should exist that leads to 737 Max. The word "sync" has implications way beyond the concerns of a mobile developer.

So I call bullshit; the fact the industry does it, that everyone does it, that you consider "real" mobile devs to require it, that customers want it doesn't mean it is a good idea or that it's mathematically or scientifically sound. It may cover most cases and nobody may notice the problems except once in a blue moon but that doesn't make it right because operational systems need full data integrity.

The correct way to handle such a request is not to "sync" but to collect data push it to the backend and let the backend sort out the mess. Not "sync" by whatever stretch of the imagination no matter what cottage industry or cult beliefs have been born of it.

Depends on the business model. If you sit on the bleeding edge all the time maybe (even if you don't you should strive for the newest possible for the skills and budget if only for retention and hiring).

But if the whole point of the company is to build some generic software that's configurable then absolutely the inside and code matters because it's a hard requirement. You could build specifically to one type of configuration but it would not solve the other. And that means generic, abstractions, reuse as part of the business case not just some nice to have for clean code.

So it very much depends. It's also possible to take it too far. As for internal release dates I have always considered them bullshit ever since I heard executives talk about how they pad the time. The more layers of management the more padding and if everyone works separately in different teams the more the padding. Developers are better off ignoring internal release dates and building the best software they think possible to not compromise on quality. They can cut scope but at the end of the day the software better work. The only thing you shouldn't ignore is warning people if it will go over time. Since 50% of software goes over time that's expected.

Either it's good or it isn't either it works or it doesn't and the timescale devs are used to (sprints, days, stories etc) don't have any bearing on reality. If it takes a month more because it has to that's how long it takes. The concept of "MVP" or feature set is totally separate from a good piece of software; once you get there you can release and iterate and improve. And it's called "minimal" for a reason if you stop there your software is sunset. The features and improvements have to keep rolling.

I notice this a lot on apps in the subway (who doesn't) and the app just dies

A lot of problems in life can be simply avoided this is no different... If you're getting that tiny last bit of differentiation because you're 90% market share and you can afford to hire people to solve that exact specific problem then great. But that isn't most places. Most apps would do better to 100% avoid the problem and just say "No Internet Connection" if there's no WiFi or 3g. On top of that you get mobile developers who swore to God they solved this problem but guess what they actually have no idea what they are doing. They think it works but it doesn't because it's actually a database concurrency control problem. This https://www.postgresql.org/docs/current/mvcc-intro.html and what I expect for someone who claims to "solve the problem" not some "algorithm" they invented.

So I don't buy it, and I don't buy the business need for it unless it's an app specifically made for disconnected use. Unfortunately it sounds like one of those things people do to make themselves feel important or smart (no nice way to put it; I see it as bad as someone who invents their own encryption "algorithm" without realizing how ridiculous that is).

In short I would say don't do it. And if someone does it better be a real business requirement.

I think if "4 hours a week" means "spend 400 hours or 4000 hours then you can spend 4 hours a week" it's more honest. In short I think it's more honest to say, you might have to give up your lifestyle for awhile or have it be a small part of your life... For months or years. And have no guarantee of success.

It's not irrelevant it is key because it means giving up the way you live. It is important to go into it eyes wide open so if you lose you know how to try again or recover.

It's not a contempt I think it's a great idea I might even do it one day but the hidden catch of "lifestyle business" exists enough. And people deserve to know and compare with someone working their ass off, and compare chances of success.

This is a way. But you still focused on craft. You just took much longer to do it and in smaller chunks. Also you probably underestimate your own skill or have some perfect combination of skills to makeup for lack of focus.

It's possible that for most people your way wouldn't work and the alternative way (putting in a lot of time) works better. Also at the start you could not have put in only 4 hours. You put in hundreds if not thousands of hours and only in maintenance mode do you go down to nothing. There's probably time you aren't counting either. All your life led up to that moment and all that.

So I think you and people like you are the exception and saying what the OP says is much more realistic and widely applicable. It's simply not possible to get where you want to go without putting in time (talent luck market and perseeverence could lower time to near zero but that's the exception).

If you want authentic and high quality you need craft.

If you're not building a lifestyle business you need craft to operate as a business.

Who do you really think has a chance at success the guy who works 4 hours a week or the guy who puts time in their work?

You need more but you need different kinds. There's no way to avoid the work, and you got to be good at the work to get anywhere. Marketing is a craft so is sales so is raising money so is writing. There's no way around it and "4 week work week" is probably more applicable to the time of dropshipping, blogging, affiliate marketing and other lifestyle business than anything concerned with "time to market".

Ignore craft at your own peril (cannot go anywhere without a very experienced CTO).

Well capitalism is about arbitrage, so yeah you can buy low and sell high somewhere else. Problem with that is everyone does it and there's no market differentiation.

I absolutely think you need craftsmanship. If you don't have it you have to pay for it or find someone who does. If you open a restaurant you need a chef if you release music you need a singer if you write code you need some developer to give you an edge.

You can be some generalist who's good at raising money and coding at the same time to save some pennies or you can be really good at raising money and hire someone to deal with the coding. The second is way more likely to succeed. Not to mention you can usually tell what startups will succeed by one simple test. Walk around their shop after hours and on the weekend, the ones that will succeed have people (persons) working after hours. At least, that's one way of telling.

So there is no avoiding your craft if you build a product. Yes you can be generalist in your approach and solve general problems but to build a big enough box to catch everyone you have to be very, very good at building boxes.

The alternative is to constantly raise as much money as possible and hire everyone under the sun but eventually you will run up against a wall. If you can raise Series A B C D E F H ad infinitum rounds and become the next Uber sure you can hire "generalist" programmers who only know algorithms and nothing domain specific or technology specific but then you are just shifting the problem... Instead of guy who has 30 years of C++ you hire guy (or girl) who can raise so many money bags your company takes over the world.

So you always need craftsmanship of some kind and the less you have the more money you need (which is a craft itself).