This is a tired take. Can a company not legitimately improve their product/offering without this being accused at them?
If you are referring to GH being owned by MS now, it's 2020 for godsake. Can we move on from our fathers' trauma? MS has been damn good lately in support of developers and developer tools.
I get just as tired of reading this take as the next person, but I don't necessarily think we should do away with it - it'd be akin to ignoring history.
I personally remain very uncomfortable with how massive GitHub has become and how ~99% of software development happens on the platform.
There isn't much lock-in yet though. If you wanted to move a project from github to gitlab, you could move the code over with a few commands. Open issues and stuff could be moved over with a script. There isn't much 'network effect' that means your project would die on other hosting.
Looking at the history in the wikipedia article that was linked in the GP post, none of the executives who used that phrase are with the company anymore.
Subtract the bare assertions and questions and your argument boils down to "it is $current_year, and Microsoft has been good lately." Which, I think you might agree, doesn't contain a lot to convince someone who remembers the bad old days.
To me, this isn't a real counterexample, even at the height of MS's EEE, it was never at the expense of developer tooling, it was at the expense of openness. In fact, improving developer experience was the primary lever MS used to achieve it.
They are similar in that they are all job frameworks and you can run background jobs through them. Runly tries to be more prescriptive than Hangfire/Quartz in that jobs should process lists of items. We think this captures a lot of problems that developers deal with everyday. It also allows us to build goodies on top of jobs like multi-threading, retries, scaling, and UI status/progress. Check us out at https://www.runly.io
Progress reporting is something my company's in-house offline processing system has been lacklustre at (we overloaded it with a ton of uses like chained processes, without considering the usability penalty when managing this without an appropriate UI).
Does Runly have some way to set up something like a dependency graph, such as
/--B--\
A---+ +---D
\--C--/
---->time---->
such that it can show you "hey, part B failed and this is blocking part D"?
Something I've known for a while (but have really come to terms with more recently) is just how important writing skills are even for technical people (even coders). It's hard to get anything done if you can't convince people why they should listen to you.
Especially in this increasingly remote-connected world, writing skills are key.
>how important writing skills are even for technical people (even coders).
Especially coders. Writing clear programs is a lot like clear writing. A function is like a paragraph of a text. It should meaningfully abstract one concept of your higher level logic. It should be introduced by a clean input from the previous "paragraph", and produce an output that is the input for the next "paragraph".
If your higher level function becomes too large, you can create larger structures like sections in writing.
Having this ability to mercilessly copy edit, paring down your functions to their core concept and putting them into meaningful context is really useful if you want others to understand your code.
All this that you write about code is correct, but I think you are missing the parent's point. Coders also need to be good at writing non-code text for humans. There is documentation to be written, and bug reports, and proposals for new features, etc. I have colleagues who are brilliant developers, and when they propose something I'm sure their idea is technically sound, yet often I don't understand what they are trying to say because their writing is much poorer than their coding.
I wouldn't say I'm missing the point. I agree that coders need to know how to write text. My point was that for coders writing is not the thing you do on the side, coding itself IS writing.
That's why I said that "even" should be "especially".
Could not disagree more. Documents are props. They exist to help your stage production evoke feelings of gravitas and rigor, but this is driven more by form than substance. It’s a similar story for large officially scheduled meetings. Real communication happens in the hallway outside just after the official document review, and is pretty much independent of what was in the document.
That's why executives of big cos get paid big money. They are held accountable (or should be anyway) for the actions of their company. The buck stops with them so to speak.
If the thing is really a big deal, as in this case, maybe the exec should do more than just "send an email" and assume everything is fine.
Your "control" of your code is an illusion if you publish it as open source. This policy now makes clear the way it already works (or should have in the case of last week).
Curious if anyone else has tried it and what the HN community thinks of the scientific claims.