506 karma · joined April 7, 2013
I've never seen this done well. You constantly end up fighting the formatting. You end up having to learn obscures combinations of key strokes to make it do what you want. Or you just give up and format the text after you've written it all.
That to me is a real loss. I highly value being able to format on the fly.
This problem is largely due to the closed and archaic nature of the GDS systems that are the source of truth. These systems have been running for 40+ years and no one wants to touch them to make substantive changes. As a result, modernisation is attempted via layers on top of layers that just add complexity confusion.
There is a difficult routing and fare calculation problem here, coupled with a distributed consensus problem. While better solutions to this exist or may exist, the biggest hurdles are the organisational ones.
Word has a lot of features and, for certain publishing needs, these are important.
But what gsuite adds is usability. You no longer need shared drives. You no longer need to email docs around, you no longer need Spec_new_v3_new.doc.
I don't even need my computer any more, I can use anyone's.
I also don't need the immense amount of publishing and formatting options word provides. What I need to do is create documents that can be shared and collaborated on easily.
Other than that, what specifically did it enable that the other phones didn't?
It also becomes more complex as your domain grows and the complexity / number of events increases.
Finally it can introduce a high degree of coupling, which ironically is something event modeling hopes to decrease. In this case if you have 5 or 6 consumers all building their own read model, but relying on specific events, the consumers are more deeply coupled into the services that emit these events.
They now all need to be updated if something fundamental changes in the systems supplying events.
I'm our case we used two techniques to mitigate this: - defined 'public' events with a clear api. These are the only events any external consumer should consume. Yes, it introduces some versioning ave migration issues, but also creates a clear and very helpful boundary. - defined read model as it's own domain and gave it a service. This is not always usable, but in many cases the model clients need of the entire system is fairly standard. This way they can integrate with a more typical query to pull the model rather than building it from scratch
Those patterns are useful (CQRS and ES), and they imply a certain design, but event modeling and domain driven design are what really tie systems together.
One thing I'm not sure I entirely agree with though is the flat cost of change. We've been working on an event modeled system for about 4 years now. It has grown in complexity and we've learnt a lot and we've invested a lot.
At this point we are probably approaching a flat cost, but initially our cost increased quicker than a traditional project.
There are a lot of pitfalls and learnings about building a system this way. Building read models gets very tiresome, and dealing with concurrency and idempotency are still hard (you just have a better tools / language for dealing with them).
Having that, once you break the back of this and build the internal skills, it is a great way to work and I really believe the systems will scale much more easily (both in performance and feature capacity). It's worth realising the effort to get there is substantial tough.
But also thinking that the larger the angle to the ecliptic, the less likely it was something that just happened to be in a very large orbit around our solar system.
From the discussion above though it sounds like the eccentricity tells us that anyway.
Having said that, the distance and duration means that only a small portion of this journey would be under acceleration, the rest would be in zero g.
Spending a century in zero g would probably have a bunch of strange side effects and almost certainly mean that the people alive when they arrived wouldn't be able to stand the planets gravity.
This exact topic is what about 80% of The Expanse is about.
Given the total journey would be ~40,000 days the 230 days of acceleration probably isn't going to impact things too much. Even if you brought it back to 1g acceleration, it's still only around 700days out of 40,000.
Club house has done a great job of organising information into stories, epics, milestones, projects.
All task manager products have some variation on these components but I've found clubhouses organisation of them to be the best.
It allows you to very quickly view the data differently depending on the context: stand up, sprint planning, PM trying to figure what's going on and what should be next.
My gut is that it turns out the way developers want to organise there work is actually a really sensible way of doing it, and so it scales up the management stack well.
We are so dead set on maintaining our resource sector, in particular coal, that there seems to be no acknowledge that a crash is coming.
Yes, the price is high right now, which is great as a producer. But at some point there will be an inflection: the high price of coal, vs decreasing renewables and improvements to grids will mean coal plants become less and less untenable.
The price will crash, we'll be left with a massive oversupply of both the resource and the infrastructure. The communities that pushed for coal mines because they provide employment are going to be left with nothing.
In the end, mines like the Adani's Carmichael mine will fail with only a small amount of the resources extracted.
This is a great result for the climate, more coal left in the ground, it's just an ass about way of doing it that's going to wreak havoc with our economy.
More to the point, all drivers seem to use multiple apps. I often get my food in bags from the wrong company. The barrier to switching for drivers _and_ the customers is zero.
As a result this feels less like money spent on a unique strategy and more like money spent buying the business.
Influence and leadership are force multipliers. If you can lead people well and influence decisions (be it as a people leader, or a technical leader, or both), your experience can be learnt from by more and more people.
There is no doubt that leadership involves doing 'management' more often than not. But it's just one aspect, it's not the end in itself.
I strongly believe in technical tracks and I've seen them work. Every place I've worked had technical positions that are peers to managers, at every level. They worked alongside managers, and did not report to them.
Progression on both managerial and technical tracks requires skills in leadership. Whether that is people leadership or effective technical leadership, the principal's are the same. You need effective communication, clear articulation of ideas and an ability to influence and lead.
If you focus solely on your technical skill and implementation ability, then it is going to get harder and harder to progress. At a certain point an exceedingly skilled individual starts adding less value to the team they are in, unless they can demonstrate real leadership.
The kitchen and wait staff were great fun. We worked in the kitchen in dead spots, we knew that business, we were actually employees.
Now I look at uber eats drivers and see people who are disenfranchised. The flexibility inherent in these models doesn't just create financial insecurity, it also creates social insecurity.
Solve small problems that deliver value in distributed way and then iterate and expand. Doing this focuses engineering on the real problems that need to be solved at the scale you are working at. This delivers real understanding of what is going on, both theoretically and specially within your domain.
The retort to this is often you'll never get to scale, or that your architecture will be incoherent. Basically you need to see the whole picture and build towards it.
The caveat is that solving small problems doesn't mean 'do something quickly or hacky'. If you do, sure you'll end up with an incoherent mess.
If you maintain good engineering practices, and focus them on real problems, my experience is you will scale your platform. These practices will keep focused on solving real problems properly, and doing so will give you an understanding of what the next problem is going to be.
I trained as an electrical engineer (but I'm now %100 software), yes there was a lot about responsibility, safety etc, but to me the core of engineering and in being an engineer is to be able to apply theoretical math and physics concepts to real world problems.
That is why I did what I did, I didn't want to be an engineer to be an on time, on budget, project manager. I did it to combine design, maths and physics to build real world solutions to problems.
And this is why I would 100% consider myself a software engineer.
The accreditation and certification is missing (so far) because we are still figuring out the best ways to apply engineering to building abstractions (which is what I believe our field is). To me this doesn't make us any less engineers.
Unless the the corporation is paying for your entire families food budget, prep, cleaning etc, I think what you have just described is exactly the point of the article: being single and having all (or most) household chores done for you is really attractive and great, having a family and needing to do this yourself for multiple people sucks and is hard.
Ergo, these perks prolong the time spent single and enjoying the perks.
But the is such huge amount of great mongering about corporate add mineral taxes that no major party will attack it.
The Minerals Council of Australia is incredibly well funded and hugely politically influential.
Me and friend both had iPods (of different generations) that got 'altitude sick'.
At two points in the trip we got about 5,000m. Each time both iPods went totally unresponsive. Both times we'd only be there for a few hours and once we descended they'd stay working again.
Obvious thing was something to do with the cold and battery, but both times the battery came at the same charged once they started working.
Can't remember exactly what the ambient temperature was (we were in cars both times) but it's puzzled me whether it was cold or altitude.
I think one of the reasons for this is that the systems people often describe when they talk event sourcing are actually _three_ different, but interrelated, architectural patterns:
- event sourcing (build your models based on immutable facts) - event driven (side affects triggered by messages, often delivered by queues) - workflow / state machine
It takes a long time to get these concepts straight. In our case once it was untangled, our framework can quite clearly demonstrate how they relate: messages update the state in a workflow engine, this triggers side effects, the results are captured as facts and used to build the model, repeat.
This worked for our use case, in which our transactions have a strong workflow, it may not work in other cases.
Finally the one point I'd certainly reinforce from the article is: _don't reach directly into the event stream_. This causes huge amounts of coupling. Instead, we ended up using bounded contexts to define our systems, and then treat key events as our API. It sounds counter to some of the ideals of event sourcing, but it is absolutely needed once you grow past that toy phase.
We try to ensure that our support tools make these situations, and the resolutions, as clear as possible to our customer agents.
Ultimately, we are on the hook for this booking so it's in our interest to get it resolved for the customer so they are happy. Our stats show that this only happens to 0.5% of bookings, but if they aren't handled well, they take up a much larger amount of support time and then end up with an unhappy customer.
Over the last few years I've come realise that this is a fundamental cost of building travel software. You can't gloss over these problems or push them back on the customer, otherwise you simply won't have any customers left.
Maybe this doesn't confirm strictly to the philosophical definition, but as an analogy I find it succinct and useful.
Many times I've fallen in the trap of absolutely _knowing_ in my head the reason things are the way they are, only to find out later I'm completely wrong. In most cases the evidence was right in front of me, but software is hard and complex and it is easy for even the best developers to miss the obvious.
Putting a term around it, having an article like this to discuss with the team, these are all useful for reinforcing the idea that we need to continually challenge or knowledge and question assumptions.
The other thing to note is that decentralisation isn't just about ideology. If we forget finance and focus on data, a blockchain solution may in the future provide the ability for open federated data that is provably correct and can operated on transactionally.
Think flight availability: right now the majority of flight ticketing is controlled by Amadeus. A highly centralised, controlled and opaque service. Assuming _many_ technical problems were solved, a blockchain flight ticketing service could allow anyone to run a local node with real time availability that was guaranteed to be correct.
Even if this was run be a federation of providers, it would be a better solution than the current one.