A few hours later another programmer came up with the prototype of a much faster terminal renderer, proving that for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking.
I have no idea if this is the case here, and I suspect it might not be, but pretty much every time I've seen a developer complain that something is slow and then 'prove' that it can be faster by making a proof-of-concept the only reason theirs is faster is because it doesn't implement the important-but-slow bits and it ignores most of the edge cases. You shouldn't automatically assume something is actually bad just because someone shows a better proof-of-concept 'alternative'. They may have just ignored half the stuff it needs to do.
This particular case was discussed at length on Reddit and on YC News. The general consensus was that the Microsoft developers simply didn't have performance in the vocabulary, and couldn't fathom it being a solvable problem despite having a trivial scenario on their hands with no complexity to it at all.
The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] and was more correct than the Windows Terminal!
[1] Features relevant to the debate at any rate, which was that it is possible to write a high-performance terminal renderer that also correctly renders Unicode. He didn't implement a lot of non-rendering features, but those are beside the point.
And the experienced developer is Casey Muratori who is somewhat well known for being a very experienced developer. That makes it less likely that he doesn't know what he's talking about and is skipping over hard/slow features.
I found it very funny that the Hindi sample text on display, in the YouTube refterm demo, means “You can wake up someone who is sleeping, but how do wake up someone who is hell bent on pretending to sleep?”.
A bit out of topic but has anybody followed performance issues of Microsoft Flight Simulator 2020? For more than half a year it was struggling with performance because it was CPU heavy, only loading one core and etc. Barely ran on my i5 6500. Fast forward half a year, they want to release it on XBox. MS/Asobo moves a lot of computation on GPU, game starts running smoothly on the very same i5 with maximized quality settings.
You just begin to wonder how these things happen. You would think top programmers work at these companies. Why would they not start with the good concept, loading GPU first etc. Why did it take them so much time to finally do it correctly. Why waste time not doing it at the beginning.
Sometimes you don't know you have a performance problem until you have something to compare it to.
Microsoft's greatest technical own goal of the 2010s was WSL 2.
The original WSL was great in most respects (authentic to how Windows works; just as Windows NT has a "Windows 95" personality, Windows NT can have a "Linux" personality) but had the problem that filesystem access went through the Windows filesystem interface.
The Windows filesystem interface is a lot slower for metadata operations (e.g. small files) than the Linux filesystem interface and is unreformable because the problem is the design of the internal API and the model for security checking.
Nobody really complained that metadata operations in Windows was slow, they just worked around it. Some people though were doing complex build procedures inside WSL (build a Linux Kernel) and it was clear then there was a performance problem relative to Linux.
For whatever reason, Microsoft decided this was unacceptable, so they came out with WSL 2 which got them solidly into Kryptonite territory. They took something which third party vendors could do perfectly well (install Ubuntu in a VM) and screwed it up like only Microsoft can (attempt to install it through the Windows Store, closely couple it to Windows so it almost works, depend on legitimacy based on "it's from Microsoft" as opposed to "it works", ...)
Had Microsoft just accepted that metadata operations were a little bit slow, most WSL users would have accepted it, the ones who couldn't would run Ubuntu in a VM.
> The "complaining developer" produced a proof of concept in just two weekends...
That developer also was rather brusque in the github issue and could use a bit more humility and emotional intelligence. Which, by the way, isn't on the OP blog post's chart of a "programmers lifecycle". The same could be said of the MS side.
Instead of both sides asserting (or "proving") that they're "right" could they not have collaborated to put together an improvement in Windows Terminal? Wouldn't that have been better for everyone?
FWIW, I do use windows terminal and it's "fine". Much better than the old one (conhost?).
That sounds like you've never seen performance of a heavily worked-on subsystem increase by 10x because one guy who was good at that kind of stuff spent a day or two focused on the problem.
I've seen that happen at least 10 times over my career, including at very big companies with very bright people writing the code. I've been that guy. There are always these sorts of opportunities in all but the most heavily optimized codebases, most teams either a) just don't have the right people to find them, or b) have too much other shit that's on fire to let anyone except a newbie look at stuff like performance.
More generally, in my experience performance isn't looked at because it's "good enough" from a product point of view.
"Yes it's kinda slow, but not enough so customers leave so who cares." Performance only becomes a priority when it's so bad customers complain loudly about it and churn because of it.
I’ve seen it at least as many times, too. Most of the time, the optimization is pretty obvious. Adding an index to a query, or using basic dynamic programming techniques, or changing data structures to optimize a loop’s lookups.
I can’t think of a counter example, actually (where a brutally slow system I was working on wasn’t fairly easily optimized into adequate performance).
I don't know about you, but I was really laughing out loud reading that GitHub conversation.
GPUs: able to render millions of triangles with complex geometrical transformations and non-trivial per-pixel programs in real time
MS engineers: drawing colored text is SLOW, what do you expect
P.S. And yes, I know, text rendering is a non-trivial problem. But it is a largely solved problem. We have text editors that can render huge files with real-time syntax highlighting, browsers that can quickly layout much more complex text, and, obviously Linux and Mac terminal emulators that somehow have no issue whatsoever rendering large amount of colored text.
To be fair to the MS engineers, from their background experience with things like DirectText, they would have an ingrained rule-of-thumb that text is slow.
That's because it is slow in the most general case: If you have to support arbitrary effects, transformations, ligatures, subpixel hinting, and smooth animations simultaneously, there's no quick and simple approach.
The Windows Terminal is a special case that doesn't have all of those features: No animation and no arbitrary transforms dramatically simplifies things. Having a constant font size helps a lot with caching. The regularity of the fixed-width font grid placement eliminates kerning and any code path that deals with subpixel level hinting or alignment. Etc...
It really is a simple problem: it's a grid of rectangles with a little sprite on each one.
It's more subtle than that. What the Microsoft engineers are saying is that the console's current approach to drawing text is inherently slow in this particular case, due to the way the text drawing library it's based on uses the GPU. The proposed solution requires the terminal to have its own text drawing code specific to the task of rendering a terminal, including handling all the nasty subtlties and edge-cases of Unicode, which must be maintained forever. This is not trivial at all; every piece of code ever written to handle this seems to end up having endless subtle bugs involving weird edge-cases (remember all those stories about character strings that crash iPhones and other devices - and the open source equivalents are no better). It's relatively easy to write one that seems to work for the cases that happen to be tested by the developer, but that's only a tiny part of the work.
Simply shaping text using state of the art libraries (like harfbuzz) can take an INCREDIBLE amount of time in some cases. If you're used to rendering text in western character sets you may think it can always be fast, but there are cases where it's actually quite slow! You get a sense for this if you try to write something like a web browser or a word processor and have to support people other than github posters.
Of course in this case it seems like it was possible to make it very fast, but people who think proper text rendering is naturally going to be somewhat slow aren't always wrong.
Saying that text rendering is "largely solved" is also incorrect. There are still changes and improvements being made to the state of the art and there are still unhappy users who don't get good text rendering and layout in their favorite applications when using a language other than English.
I understand the scepticism about such claims, but Casey's renderer is not a toy, and handles a number of quite dificult test-cases correctly. He solicited feedback from a sizeable community to try and break his implementation. The code is vailable here: https://github.com/cmuratori/refterm
refterm is designed to support several features, just to ensure that no shortcuts have been taken in the design of the renderer. As such, refterm supports:
* Multicolor fonts
* All of Unicode, including combining characters and right-to-left text like Arabic
Glyphs that can take up several cells
* Line wrapping
* Reflowing line wrapping on terminal resize
* Large scrollback buffer
* VT codes for setting colors and cursor positions, as well as strikethrough, underline, blink, reverse video, etc.
The really hard part of writing a terminal emulator, at least from my experience working on Alacritty, is fast scrolling with fixed regions (think vim).
Plently of other parts of terminal emulators are tricky to implement performantly, ligatures are one Alacritty hasn't got yet.
Reading the thread itself, it’s a bit of both. Windows Terminal is complex, ClearType is complex and Unicode rendering is complex. That said… https://github.com/cmuratori/refterm does exist, does not support ClearType, but does claim to fully support Unicode. Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2 and (b) it sounds like the Windows Terminal project is indeed a bit more complicated than can be hacked on over a weekend and would need extensive refactoring to support the approach. So it sounds a bit more like a brownfield problem than simply ignoring half the things it needs to do, though it probably does that too.
As good as Casey Muratori is, Microsoft is more than big enough to have the means of taking his core ideas and implement them themselves. It may not take them a couple weekends, but they should be able to spend a couple experienced man-months over this.
The fact they don't can only mean they don't care. Maybe the people at Microsoft care, but clearly the organisation as a whole as other priorities.
Besides, this is not the first time I've seen Casey complain about performance in a Microsoft product. Last time it was about boot times for Visual Studio, which he does to debug code. While reporting performance problems was possible, the form only had "less than 10s" as the shortest boot time you could tick. Clearly, they considered that if VS booted in 9 seconds or less, you don't have a performance problem at all.
Something tells me that the half-a-dozen to a dozen of Microsoft developers working on Windows terminal:
- could go ahead an do the same "doctoral research" that Casey Muratori did and retrace his steps
- could pool together their not insignificant salaries and hire Casey as a consultant
- ask their managers and let Microsoft spend some of those 15.5 billion dollars of net income on hiring someone like Casey who knows what they are doing
> Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2
One thing to remember is that it is always possible and acceptable to contact the author of a GPL-licensed piece of code to enquire whether they would consider granting you a commercial license.
It may not be worthwhile but if you find exactly what you're looking for and that would take you months to develop yourself then it may very well be.
Why is that a problem? A GPLv2 terminal would not be a business problem for Microsoft. People would still have to buy licenses for Windows. Maybe they would lose a little face, but arguably they have already done so.
At least it’s not GPLv3 which this industry absolutely and viscerally hates (despite having no problem Apache 2.0 for some reason, Theo de Raadt is at least consistent).
> Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2
That's not unfortunate. Having people who work on competing Free Software is a good thing. It would be even better if Microsoft adopted this code and complied with the terms of the GPL license. Then we won't have to deal with problems like these because they'd be nipped in the bud. And we would set the precedent to take care of lot of other problems like the malware, telemetry, abuse of users' freedoms.
It's the hardest thing about building perf-related PoCs. Every time I've built a prototype to prove out an optimization, I've spent the entire duration of the project watching the benefit shrink, stressing that it would dwindle to nothing by the end. So far, I've been lucky and careful enough that I haven't convinced a team to expend massive resources on a benefit that turned out to be fictional, but I've had it happen enough times at the scale of a p-day or two that it always worries me.
Counterexample: WireGuard. Turns out OpenVPN was massive and slow for no reason and it only took one (talented and motivated) man to make a much better version.
> > for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking.
> You shouldn't automatically assume something is actually bad just because someone shows a [vastly] better proof-of-concept 'alternative'.
Apparently you should. I can confirm that the first quote is a appropriate assessment of the difficulty of writing terminal renderer. Citation: I did pretty much exactly the same thing for pretty much exactly the same reasons when (IIRC gnome-)terminal was incapable of handing 80*24*60 = 115200 esc-[-m sequences per second, and am still using the resulting terminal emulator as a daily driver years later.
>> I have no idea if this is the case here, and I suspect it might not be, but pretty much every time I've seen a developer complain that something is slow and then 'prove' that it can be faster by making a proof-of-concept the only reason theirs is faster is because it doesn't implement the important-but-slow bits and it ignores most of the edge cases.
Even in those cases it usually turns out that the handling of edge cases was considered reason enough to sacrifice performance rather than finding a better solution to the edge case. Handling edge cases probably should not cost 10x average performance.
Not necessarily, often times, especially in big corporations programmers will be incentivized to deliver things quickly, rather than to provide the optimal solution. Not because they are bad at programming, but because they have quotas and deadlines to meet. Just remember that story of how in the first Excel version a dev had hard-coded some of the cell dimension calculations as they were under pressure to close as much tasks as fast as possible.
The one example that comes to mind is file system search.
I am writing this application that displays the file system in the browser in a GUI much like Windows Explorer or OSX Finder. It performs file system search substantially faster than Windows Explorer. Windows Explorer is written in a lower level language with decades of usage and experience where my application is a one man hobby project written in JavaScript (TypeScript).
The reason why the hobby project is so substantially faster than a piece of core technology of the flagship product of Microsoft is that it does less.
First, you have to understand how recursive tree models work. You have a general idea of how to access nodes on the tree, but you have no idea what’s there until you are close enough to touch it. File system access performance is limited by both the hardware on which the file system resides and the logic on the particular file system type. Those constraints erode away some of the performance benefits of using a lower level language. What ever operations you wish to perform must be individually applied on each node because you have no idea what’s there until you are touching it.
Second, because the operations are individually applied on each node it’s important to limit what those operations actually are. My application is only searching against a string fragment, absence of the string fragment, or a regular expression match. Wildcards are not supported and other extended search syntax is not supported. If you have to parse a rule each time before applying it to a string identifier of a node those are additional operations performed at each and every node in the designated segment of the tree.
For those familiar with the DOM in the browser it also has the same problems because it’s also a tree model. This is why querySelectors are so incredibly slow compared to walking the DOM with the boring old static DOM methods.
> pretty much every time I've seen a developer complain that something is slow and then 'prove' that it can be faster by making a proof-of-concept the only reason theirs is faster is because it doesn't implement the important-but-slow bits and it ignores most of the edge cases
It's still a good place to start a discussion though. In such a case, apparently someone believes strongly that things can be made much faster, and now you can either learn from that person or explain to them what edge cases they are missing.
Except that in this case it’s the other way around. This weekend project has better support for things like like ligatures, combinations of Arabic characters, RTL, etc
...So none of these typical hand-wavy dismissals apply:
1. "Is it really faster for edge cases"
2. "He probably didn't implement certain features like Arabic and Chinese"
3. "Businesses just wants enough"
4. "Businesses just wants enough"
5. "It probably makes some closed-world assumption"
The performance of RefTerm didn't come from some big tradeoff; it came from using the right perspective and keeping things simple.
Sure, past a certain complexity threshold, you'd have to work for extra perf, but from my observations, folks who immediately jump to the wrong implicit conclusion that "good perf must have required compromises" got conditioned to think this way because the software they work on are already (often unnecessarily) complex.
I don't think dismissal 1 applies anyway - even if RefTerm didn't implement, say, variable-width fonts - you could just build a terminal that uses RefTerm's fast algorithms for the common case, then falls back to the Windows Terminal's slower algorithms for the more general case.
Yup, this. Something I've been ranting about[0] for a while: there is no technical progression ladder. The Senior->Principal-> ... path seems to be a faux-management track, with all the managerial responsibilities and little of the authority. Software is shitty in big part because it's mostly written by juniors, as almost anyone who has any clue moves over (or gets pushed over) to managerial or faux-managerial roles.
I've been thinking about a more charitable interpretation of this recently. Another thing I rant about[1] is that tools we use for programming are not expressive enough. It takes too much work to say simple things, the coding feedback loop is ridiculously long. So how this connects? In a way, junior programmers can be seen as a Mechanical Turk version of a Sufficiently Smart Compiler - it lets the more experienced people skip some of the tedium with the tooling and deal with higher-level concepts, which get translated to actual code by an army of juniors and interns. Except, this doesn't work that well - the coding feedback loop is even slower.
This definitely resonates. I've often talked about how the key transition to 'lead engineer' is when you learn how to wield a team of programmers to solve a technical problem, instead of solving it yourself, and to higher levels it's when you learn how to wield an entire organization to some technical purpose.
These ARE much clunkier tools than a compiler.
Another way I've expressed it is how the tool you use to get started on implementing a change shifts as you grow more senior (if you'll forgive an IDE-centric kind of view - this is meant to reflect life in a Big Org - feel free to substitute with appropriate emacs commands)
- Junior Dev: File > Open
- Dev: File > New
- Senior Dev: File > New Project
- Lead Dev: File > New Diagram
- Principal Dev: File > New Powerpoint Presentation
There may be a sort of sweet spot in the progression where a programmer can advance to a point where they spend most of their time figuring out the code architecture (maybe with a skeleton) for others to implement the details of, with some code reviews here and there, rather than coding as much themselves (but they still code, especially the critical pieces). This lets them still be a key player as far as programming is concerned but there's also a space for more junior programmers to learn and grow without trashing the whole project in the process. The Godot engine seems to be turning into this sort of sweet spot model with its tech lead. However in a company this seems like an unstable situation, since I've seen such leads advance another step and now the only thing they "architect" is business strategy via all-day meetings, like any other executive, and the last time they coded anything was years ago. You might get them on a rare code review but they've become so far removed from the details they're not as helpful as they used to be, which in turn leads to not including them anymore. This distance hurts again because now that they have at least some influence (not as much as the 'equivalent' managerial track position, 'mysteriously') to address long-standing dev pains they are too far removed from the pain to spend their limited influence fighting it.
My own filter for how likely a company is to fall (or be) in this trap: does the CTO code at all?
>> spend most of their time figuring out the code architecture (maybe with a skeleton) for others to implement the details of
I think a good use of the experienced programmer is to write some critical components well. I'm also with you on system level design: These are the important interfaces, you write this piece and you write that one.
Another example, I have an Oculus Quest 2 VR headset. It was fantastic when I got it in March. Now they've got some glitches where the rendering STOPs for a brief instant and the view is not updated with motion. I'm wondering if this is because John Carmack is no longer full time there and someone compromised some design principle in order to implement something. Once the glitches are in, they're going to be very hard to get back out as time goes on.
There is that joke about the University Professors talking about the best high level language, throwing out various languages until one just replied with "Grad Student".
It does make a lot of sense, you describe the problem in a very high level and abstract way and at the end of the process you get an executable out of it.
But yeah, as you go up the ladder, even the technical one, you end up needing people skills more and more than any technical or programming skill. Usually by senior level you're the best that you'll ever be at technical topics (hand wavy description here, don't nitpick), and the only way to progress up is to improve communication. No amount of extra technical knowledge will help you if you cannot communicate well.
Juniors are beginners, learners, apprentices, and are bound to make mistakes and design things poorly. The issue is there are so few high-quality engineers relative to the demand, and it's hard to prove who is high-quality before they're onboard for a few months. So, if someone is high-quality, you really don't want to lose them, so you promote them, pay them more, try your best to keep them on-board. There's a benefit to elevating them out of the weeds, because often they can glance at the weeds and tell someone else how to clean it up easily, without spending their effort to actually do it.
Furthermore, they can glance at 10 patches of weeds, 10 junior engineers, and find the couple that need more guidance than the others. They can leverage their knowledge through others, assessing their strengths/weaknesses as coders in ways juniors never could.
It seems like companies are creating independent contributor tracks to remedy this issue. You can have people who are legendary programmers float around and contribute where they wish.
This is well-said and resonates with me quite a bit. How do we build expertise in an engineering organization where the best engineers are incentivized not to engineer?
I really appreciate this perspective. Better tooling to enable individuals to penetrate more layers of abstraction sound great. To some extend e.g. with cloud providers this is already happening. We have more powerful building blocks than ever.
However, I feel the idea of experienced vs. junior programmer is not helping this discussion much. Experience can also hurt to some extend, because you need to unlearn things.
> To some extend e.g. with cloud providers this is already happening. We have more powerful building blocks than ever.
This is not ideal though. Cloud services have a pretty short half-life, and trap you in business relationships that you shouldn't need just to build software.
(I know, I can't stop complaining.)
> I feel the idea of experienced vs. junior programmer is not helping this discussion much. Experience can also hurt to some extend, because you need to unlearn things.
That is true, but I still think the idea is sound - there's much more universal, transferable programming-related experience juniors gain than things they'll need to unlearn later. The problem I see here is that, just as those developers gain that experience, they get pushed out to management / faux-management. In principle, this should lead to at least some improvement in quality - as increasingly better people are tutoring the next generation and directing it - but I feel we've reached a fixed point in terms of software skill, with most software being written at a pretty low level.
This reflects a lot of what goes on in Academia as well.
Also, if you think you can counter a "that's not possible" with a working proof of said thing working, think again, most people don't like to be shown they're wrong, particularly tenured professors. That's one of the fastest ways to sabotage your own developing career.
"Yes men" climb the ladder much easier, but then work doesn't do itself so that's the catch. Cue exploitation of interns and other newcomers and you almost have the whole picture on how things get actually done. Hence why "science advances one funeral at a time". Once someone reaches its own Peter level [1], it stops being a productive force and becomes a plug that jams everything behind it.
I had a Physics 101 professor who gave a test that had a problem involving blowing a fan into a sailboat sail. The answer to the question was supposed to be that the sailboat doesn't move anywhere because of Newton's 3rd law, but one guy in the class spent close to the entire exam on that one problem showing that it would slowly move forward using a conservation-of-momentum-based approach instead of a Newton's 3rd law approach. The TAs marked it wrong and he got a low score on the test because he spent so much time on that one problem. He tried to argue about it to the professor in lecture but the professor shut him down saying to come discuss it during office hours. So he made a demo using a pinewood derby car with a hand fan glued to it and brought it to office hours and proved that it would move forward. The professor was super humble about it and brought the demo to lecture the next day and publicly gave kudos to the student for challenging the status quo.
I would really be surprised if any tenured professor would shut down a solution to a well known hard problem just based on his ego. More likely the solution is not as well presented, researched or thought through as it seems (I'm assuming we're not talking about astrophysics here).
It really depends on the person, but yes you have to get to know them to know how they will react. I find that this is more of a problem in the US, where tenured professors often develop these vast impenetrable egos, while in other countries, such as in the UK or Germany, they are more pragmatic. That said it is still entirely individual, and I knew who to avoid when I had certain ideas in my PhD.
Also, our German group leader asked me to take a feature from my software package because he was worried that the Americans would get upset at an early PhD student showing them up.
Actually I add something extra: I actually know an Indian professor who has become quite senior in the US, and is a more "famous" member of our collaboration, and he actually enjoys a "Guru figure" like perception when he returns to India. He says that literally people treat him like he is a lord or guru. Very strange
This is both annoying and understandable. For the dev team, to dive into this performance optimization would mean punting something else from their roadmap. I suspect they weighed their perceived chances of success against the projected cost and reached a certain conclusion which in retrospect seems wrong. The independent developer did not have that "hurdle" as he simply did this at the expense of whatever other fun programming challenges he may have done those weekends. It's awesome that he turned out to be right. But I suspect if he turned out wrong we'd never hear about it. There was likely no tradeoff analysis on his part in undertaking this project, while the dev team did have to do one.
On the flip side, I have seen developers get really hung up on what is academically difficult rather than what is practically doable. I had a young developer who worked for me get really upset and hung up on the fact that something he was asked to do was NP equivalent, meaning there's no non-exponential time algorithm to implement what I was asking for. It took me weeks to realize this was messing with him and then about 5 mins to dig into the data and show that input length never practically exceeds like 7, so an exponential algorithm was fine. So I can see how a dev could get stuck thinking something is really hard when it really isn't. But I don't think it makes them a bad dev, it's just hard to transcend your own perspective.
I remember clearly when I first gained a real appreciation for the importance of measuring and considering your actual data.
I was trying to optimize a slow project doing some polyhedron dissection on large (~1M polyhedrons) meshes in real-time. As a first attempt I had my sights set on a function which tried to find a certain point on a surface by making an educated guess and then iteratively bumping its estimate in the right direction. I figured "I can solve this analytically instead!".
I did, and it made things approximately twice as slow. After scratching my head and outputting some data I realized my constant time solution required a number of expensive operations including sqrt and the iterative approach ran on average ~1 iteration and at most 3 iterations for just a handful of these millions of triangles.
> I realized my constant time solution required a number of expensive operations including sqrt and the iterative approach ran on average ~1 iteration
Yeah! It's deeply unsatisfying to forego algorithmic optimization but it often isn't necessary.
EG, when I do Advent of Code, I often write a naive algorithm that works correctly on the sample input, and then runs a really long time on the actual problem input. Before I go redo the algorithm, I often run it with PyPy instead of the standard Python, and 80% of the time it terminates quickly enough.
Similarly, whenever I happen to do AoC in C++, my naive algorithms happen to magically be fast enough out of the box so I don't even think about better algorithms. It's unfortunately counter to the intuition that you get from a CS programs that obsess with Big-O notation rather than implementation speed.
Big-O is really important but it seems like the input size where it starts to dominate implementation is much larger than our intuition suggests.
(of course it's also easy to write really bad algos that suck even on small input)
Reminds me of the time I spent ten days building a memory allocator based on a red-black tree to optimize lookup times for an interpreter that needed to be fast. When I compared its performance against a linear search, it failed miserably. Turns out the fixed overhead in implementing a red-black tree vastly outweighs a naive approach when you're only dealing with 20 terms or so.
I'm not sure "It doesn't take a PhD, just years of experience" is quite the rejoinder the author thinks it is.
Aren't they both just ways of saying "It takes someone with a rare subset of highly specific knowledge to solve this problem"?
The MS person was saying "Sure, there's probably a way to make this faster but I don't have anyone on my team who knows how to do that. If I had the budget to go out and hire someone with a PhD maybe I could do it."
That then Casey Muratori could show up and do it in his spare time doesn't really refute that argument, does it? This is someeone who has spent years actually doing hardocre R&D work, and literally published techniques that advance the state of human knowledge in the field of GUI rendering[0]. His resume is kind of a living example of 'PhD, or equivalent professional experience'.
So sure, it might be nice if MS's career structure led to them having more Muratoris on staff, but I don't think the expectation that every product team should have one or two developers of that caliber on it is a reasonable one.
It IS a good argument for why MS should accept open source contributions, though.
It's not really what the MS devs said though: "I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation"
This seems to mean, nobody has ever done that, it is a research project (a doctorate thesis must be about something that has never been researched before, at least where I live).
This particular problem cannot be a PhD subject, because it has already been researched, solved and done multiple times, by different persons and on different projects.
Someone can use the knowledge already widely available on the internet to grasp what the issue is, and implement a solution in their own project.
Years of experience aren't a PhD. Years of experience can help you understand a thesis, but only if the research doesn't exist yet, can it be considered a doctoral research project.
So the comment that the 'PhD' reference was responding to was Muratori laying out how he figured a simple terminal renderer could be implemented, using two texture lookups in a single drawcall [0].
In the course of that, Muratori allowed, almost in passing, that of course you would need, in order to do that:
> a glyph atlas encoding the cell-glyph coverage in whatever way makes it easiest to compute your ClearType blending values
Now, it does not strike me as beyond the realm of possibility that that step might be suitable for academic research. It calls for an efficient encoding of cleartype-ready glyph data with comprehensive coverage of unicode glyph space (not codepoint space). That's not trivial, and - as the DHowett reply suggests - it would take a literature review to determine if someone has already accomplished this (and he also suggested that so far as he was aware this was not how any other terminal was implemented, implying this is not simply some well known solved problem).
I mean, sure, he could be wrong about that - it might be exactly how another terminal implements it; there might already be published research on the topic; or it might just be much simpler than it appears. But it's not crazy to, on glancing at that problem, consider that it seems like it might actually require genuine original high level research.
I think the other piece the comment and the rejoinder miss is is: A PhD generally means you've done four years of work post bachelors, and some of that work was novel.
A PhD alone does not make someone an expert in most modern senses in software. The folks the author describes as "experienced" often have more than a decade of working software knowledge from after their education.
Casey Muratori has 30 years of programming experience. That's not a PhD, that's a PhD and then an additional 20+ years of experience.
He wrote The Book on rendering performance. Michael's super optimized x86 assembly routines for lighting and texturing is the reason we can run Quake on toasters.
Anyway, I don't think they should hire Casey. Specially after that demonstration of not understanding the big-picture and not being a team player...
2. Since this whole affair, the developers have apologized and corrected themselves which is usually unacknowledged in these discussions.
3. The developers have made a number of performance improvements since (most of which are in the latest preview release).
4. This episode is constantly retold and used to bully the developers even after these apologies and this has lead to one of the developers to quit (paradoxically one of the devs who after these posts made the most effort to figure out where the bottlenecks are).
If that's the case, they should really link those developments/retractions/apologies in the comments of that issue. The way the comments end in that issue is a really bad look, and there's no hint to the reader that there was any further developments, either in the code or the dev team.
It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way.
Leadership is a lot more than about "shuffling paper" in an "ivory tower".
As a lead (in any decent company), you get to participate in critical design reviews; you get to read and review code; you get to shape the trajectory of others; you get to participate in discussions with the product teams. If you work smart, you get free time that you can use to keep coding. All of this can be extremely rewarding.
You are not serving our domain by painting this kind of picture of leadership. The truth is, you can excel as a software engineer, but you can also excel as a lead. And none is better than the other.
I dedicate this message to the "wet behind the ears" people you are referring to who would never consider the role if they were to stick to this poor vision you're delivering.
I agree with you, but few companies know how to appreciate those who decided to progress in the technical excellence. In most not taking a "leadership" (aka management) position means your career reaches a dead end.
> It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way.
I think you misread the post.
I don't see where this is criticizing the role of leadership. Good leaders exists (though, they are rare). I have been led by some of those inspiring people. But I've never met a leader (as good as it was) who continued to be a great software engineer.
The point is that they all were stuck in the "Sort of knows what they are doing" zone. And that's ok for being a great leader. But then, nobody in the company is kept long enough at a position to become what the author describe as "Experienced".h
> It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way.
It saddens me to time and again be stuck with "leaders" who don't know what they are talking about and think they need to weigh in on everything, even though they add negative value when they do so, because they want to justify their mostly pointless job.
In a 14 year career, I have had "leadership" that is not completely horrible for about 6 months, but that I still would not call good, at best it is mediocre. If only most "leaders" were wet behind the ears instead of bordering on grossly incompetent.
If people's experience of leadership is that it is almost always dead-weight, then the problem is that it is almost always dead-weight, not that people call it out for being almost always dead-weight.
And by the way, I have never met one person who thought they were a good leader that was even slightly so. People who think they are good leaders are almost invariably pompous, arrogant and ignorant.
Of course we have all met people who were pompous, arrogant and ignorant.
But there are some good and outstanding leaders out there. If you never had the chance to meet one (or did not recognize them when they were in front of you), I am sorry for you.
If you read the article, the author is discussing a conversation on Github and developer experience. The article isn't an indictment about academia (it doesn't even really come up at all).
Re the author's competence argument, given how complex software development is as a field, a better approach should be to always assume that there's a person out there who can solve a problem quicker and more competently than your guesstimate. Of course, you should also assume that they're not going to, and that you - with all of your issues, lack of experience, and general :/ 'iness - is the one who's either going to have to fix it or find someone who can.
The worst part is that the kind of arguments he was met with is exactly the kind of arguments people use to get headcount and climb the ladder within corporations.
Spending a little time writing a well designed and fully working solution => Good job, now take the next ticket!
Spending a lot of time explaining why something can't be done with this budget => Promoted to manager!
Spending a year of time explaining why the project need a much bigger budget to deliver features => Promoted to director!
This is neither the problem nor what the article is talking about. Your argument is so overgeneralized that i don't even know where to start taking it apart.
Cultural issues are almost always tied to performance evaluations at a company, so it is highly relevant.
If this wasn't the problem then their manager would have reprimanded them for posting such nonsense. But either these objections were made by the manager or the manager agrees with them. Why would a manager who is fine with such bullshit still have his job? Because it goes all the way up the chain, otherwise someone would have cut it off a long time ago.
I understand that different people have different skill sets, that's totally fine. I don't think every single senior developer at Microsoft should have the skillset to fix performance issues like this. That said, however, I do think developers should be able to recognize when a task requires a skill that they do not have. In those cases it's best to reach out to someone within the organization who has that skill. Or, you know, you can be a senior developer at Microsoft and condescendingly claim that it's impossible, or "takes a PhD to develop that". I guess this is what you get when you fill organizations with people who don't care about performance, computer science or algorithms.
I'm going to use this case as another example to point to when people argue that algorithm skills are useless and shouldn't be used when interviewing.
Yes it is. When you have 2 programs that do the same thing, except one program is orders of magnitude faster than the other, it's almost* always because the faster program is written with better algorithmic time complexity.
(*In some cases the big-O time complexity may be the same for 2 programs, but one program can still be much faster in practice due to micro-optimizations, heuristics, etc. Even in cases like this, people who are good at algorithms will be better at writing these heuristics and micro-optimizations than people who don't care about algorithms.)
I feel this is missing the elephant in the room, which is that experts are not interchangeable. They have typically specialized in whatever they have spent lots on time doing, and so developers in different sectors develop a lot of different skills that are typically not very useful for developers in different sectors.
A result from that is that what may be trivial for people in one sector is hard for people in a different sector, and vice versa. Often people will not know enough about sectors different from the one they operate in to know what is hard or not in other sectors.
Counter argument: If the experienced programmers stay where they are, software development will forever remain craftsmanship. A single developer can only tutor so many juniors.
In fact, I think that teaching and encouraging to learn is the most important thing in SE. And that has to begin with leadership figures that don't believe their own knowledge gets obsolete after one year just because the latest framework got released.
SE should not be an art form. It should be founded in solid science and abstraction should allow us to keep our knowledge applicable. You're not a bad engineer because you never touched the latest hypetech or programming language. You are a bad engineer if you only consider yourself a "frontend developer with react on chrome".
> SE should not be an art form. It should be founded in solid science and abstraction should allow us to keep our knowledge applicable.
Software engineering can never be anything but an art form!
A lot of fields of endeavor have both mechanical "science-based" components and creative "art form" ones. An inexperienced chef can get some productive cooking done by mechanically following the steps of a recipe someone else wrote--cutting up vegetables, operating the stove, and so on--without making culinary decisions of their own. Experienced chefs, though, come up with ideas for things to cook, which you can't effectively do just by following some procedure. You need to have some creative je-ne-sais-quoi.
In software engineering, we have no long-term need for the first category of people. Any programming task that doesn't require human creativity can be automated. (When's the last time you decided which CPU registers corresponded to which variable names in your program?) An effective programmer uses abstraction for precisely this purpose. They spend all day, every day on making the hard decisions, and they let the computer handle the rest.
This is why Enterprise Software Architecture techniques have always been and will always be doomed to fail. You can't have senior engineers come up with rules that junior engineers can just mechanically follow to write good code. If you could, you wouldn't need the junior engineers, since you could just tell a compiler or code generator or something to follow the rules instead. Everyone who works on a codebase needs to be capable of making good decisions about code, in a way you can't boil down to science and checklists, or the best they can ever do is waste their own time producing repetitive boilerplate.
If you look closer everybody who create something on work, like every craftsman, is a kind of an artist. But it pays very badly, so even for people who like the job, are forced to step up into the office, because of the better pay. That is part if the reason, why you almost can't find a good plumber or electrician. If you can count to 2, you are forced out of the job. As you long, as you write software by yourself, you are not much different than a plumber .. you work with your hands.
I get this sentiment often, but I think it is incorrect. Software developers should not consider themselves artists - they should consider themselves designers. Yes, a designer has some freedom to express themselves, but mostly they should satisfy the customer. Think of someone designing a lamp for IKEA. The functional and nonfunctional constraints outweigh the artistic freedom by far. Software developers have one advantage over the poor soul that has to come up with that lamp, though: For us there is serious, hard, science that tells us what can and what cannot work. The IKEA designer must rely on market research.
Good software development can't be anything but craftsmanship, or art if you think of "art" as in "artisan".
Think of what a developer is, and what a computer is. A computer is a dumb machine, it lacks creativity, it is only good at executing orders, but that, it does it very well, and very fast. A programmer is a human, creative and able to see the big picture, his task is to inject his human qualities into the dumb machine, so that the machine can do things that are useful for humans.
So, programming is the opposite of applying recipes, if there is a well defined recipe, that's for the machine, not for the human. If programming is not an at least a little bit of an art form, it means the programmer is doing the job of the computer, which is a waste of valuable human time on something the machine can do better.
I'm somewhere in the middle. I see software development as an art form, however it's not disconnected from its solid scientific roots.
Sometimes, the art part is for fun (i.e.: your weekend project), sometimes it's for pushing systems to the limit (i.e.: scientific programming, demoscene, or where performance is really needed).
In my case, the art is exploiting the hardware or the theory in a way that it works smoothly and very performant for the cases you have.
This doesn't mean the deadlines doesn't matter, and explicit, slow, but very robust code doesn't have its place. On the contrary, it has many places. We need to make the correct trade-offs to get our job done the best way possible.
On the mentoring side, training people is hard, because of both parties. Low ego, open mindedness and being open to being wrong is very important. I try to mentor some people around me, and I encourage them to go further than I did. Lastly, I find passing the "old way" to new generations very valuable. While these old ways are inevitably lower level and less hip, they're tried, stood the test of the time, and generally performant enough (or very performant in some cases).
Just a side note, your idea of art is a bit naive. Take for example the work done by Christo and Jeanne-Claude, citing wikipedia:
> Their work was typically large, visually impressive, and controversial, often taking years and sometimes decades of careful preparation – including technical solutions, political negotiation, permitting and environmental approval, hearings and public persuasion.
I pity the developer (or maybe manager) at Microsoft who wrote the GitHub comment on which this article's title is based. (And no, I never met him when I was at Microsoft.) If he's in the Seattle area, he's likely not even awake yet, but when he is, I expect he's going to have a bad day. Assuming he's not already sick of the Windows Terminal versus refterm drama, it would be interesting to read his perspective.
As the guy responsible for that comment (and the dev lead for the team! Hi!) I can say it haunts me pretty much weekly. My parenthetical-laden snarky sense of humor, my use of italics to indicate speech-like emphasis and pretty much everything else about that comment has been dissected to parts as small as possible.
In the end, though? Yeah, I was completely wrong. I don’t know much about graphics engineering and I’m glad(^) that we were shown up by somebody who does.
I’ve been working in software for nearly 20 years, and I’m firmly in the “knows enough to be dangerous; doesn’t know everything” category the article is missing. It’s not, as some have characterized in this comment section, because I moved into leadership; rather, it is because there is not a single axis on which to measure all engineers. I’m inexperienced in graphics and text layout, and my critical mistake was not respecting the experience somebody else brought to the table. In other fields, perhaps I fall higher on the experienced/wet-behind-the-ears scale.
(^) I may flatly disagree with his presentation and his group of fans taking every opportunity to slander us, but I’m happy that it’s generally possible for us to improve performance and engineering efficiency using the technique he described. :)
> his group of fans taking every opportunity to slander us
Conversely, I think I went overboard defending you and your team, to the point of making my own over-broad generalization about game devs in another subthread [1]. I'm glad it's practical to get the best of both worlds in this case.
My sympathies to you and the rest of the WT team. I think you’re doing a bang-up job under difficult platform constraints (that most people don’t appreciate), and the amount of vitriol spilled over this one interaction has been really disappointing.
Just remember that there’s a huge number of people who appreciate the work you’re doing to modernize terminal experiences on Windows (nearly 78k GitHub stars!)
yeah, i would be really sad if I was at the receiving end of this.
One guy is not 100% correct one day (because we overworked devs always are?), and the next day someone has written a blog text painting him as a subpar dev and now he is on front page of HN used as an example...
Yea, it's been a generally shit experience. Knowing the sense of humor of the original "PhD" comment, yea, I read that as a light-hearted jest, which was definitely lost in transit. Communicating on the internet is hard. Miscommunications are easy, and this one happened to spiral quickly. It saddens me that this whole incident was used to balkanize the community rather than to work constructively together.
The very ticket [1] is locked by this epic ending:
> You were overly confident in your opinion, but I hope this website helps you understand that it's actually really damn hard.
> The reason your program shows a high FPS under other terminal emulators is simply, because their rendering pipeline works independent of VT ingestion. Gnome Terminal is not laying out text faster than your display refresh rate either. And of course, again, this is something WT will probably do as well in the future... but this project is nowhere near as old as Gnome Terminal is.
The reporter is basically being fobbed off by being flooded by random buzzwords and data points, none of them specific, but he keeps trying to drill down to specifics by asking questions.
The tone gets quite condescending towards him.
He gets out of all this with flying colours. He should consider adding that Github issue to his resume.
He is already well-known enough in his field past the point of writing a resume, and I don't think he really would want to enter the corporate IT world that he intensely despises (even with lots of cash). Plus he's already busy on his own working on various projects: the video game 1935 (which we don't really know that much of), Star Code Galaxy (a CS course focusing on fundamentals), and Handmade Hero (A live recording / tutorial of making a game from scratch). He's already really
Yeah, typical Microsoft developers (https://github.com/microsoft/terminal/issues/10362). That issue was pretty mild, they felt threatened and used CoC principles ("combative") to shut down the threat.
This is how they also ruin "open" source projects like Python now.
That's a pretty terrible interpretation of events here. Along side the "combative" phrasing was a bit of self reflection
> Setting the technical merits of your suggestion aside though: peppering your comments with clauses like “it’s that simple” or “extremely simple” and, somewhat unexpectedly “am I missing something?” can be read as impugning the reader. Some folks may be a little put off by your style here. I certainly am, but I am still trying to process exactly why that is.
That post is literally not trying to shut down the conversation, it's simply reflecting on the tone of the commentator. elsewhere in the comment he even prompts for more discussion on the topic. At no point is the CoC invoked.
> I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively…
Yes, it might be seen as combative since it amounts to saying "you guys seem to be clueless". When proven in experiments, it means that the combativeness was justified.
Imo, the language in this quote is almost unacceptable. It's a roundabout way of saying "stand back little peon, you are not important enough to be thinking about problems that concern us."
It's inevitable that when people overestimate their competence and judgement, the moment when humility is forced on them is experienced as painful. Adjust prejudices and move on.
Saying that is is a multiyear long undertaking was probably a little silly and makes it sound like the person who said that can't have been involved wi4th the software otherwise they would have known this but there might also be another explanation that we have seen, particularly with Microsoft:
You can't sell the things that make people just like the software, only new headline features do that.
Example 1: When you open visual studio 2019, you get a search box by default that allows you to type in your project name and it looks for it in the MRU list. Except this is intolerably slow! I suspect it might not be the searching itself, perhaps a tonne of threads are doing something but it is terrible. ANY search algorithm looking through a list of no more than 50 things should be instance, theirs takes up to around 10 seconds and does fuzzy search by default! Why don't they fix it? They wouldn't sell any more units by fixing it and you won't upgrade to the newer improved version.
Example 2: When you install nuget packages in visual studio on netfx projects, it modifies the assembly redirects in web.config by re-writing the entire file even if there are no changes. Oh, and it adds extra spaces and stuff so that the diff tools think every single line has changed. I have to manually delete all of the entries, build it again, let visual studio warn me about missing redirects, double-click the warning and VS writes the file in the original style revealing the maybe 2 actual changes. This is total horsesh*t but they won't fix it. Why? You should be using dotnet core, even if your project is 5 years old and established.
It's a shame because there are lots of things to like about MS tooling compared to lots of competitors but each of these things will be a coffin nail that eventually will cause people to jump ship.
The difference here is that the developer of RefTerm is an experienced, professional developer passionate about his craft and building good software. Microsoft is a faceless entity composed of people who mostly don't care about what they do during the day and are just getting by so they can get paid. There's no shame in that. But there is shame in patronising someone when they demonstrate something to be false and locking the thread on GitHub such that no further discussion is possible...
Microsoft is sluggish and delivers products that do the job and nothing more. Sadly, that's the modus operandi of most software companies. That's why nimble little startups are still managing to steal pieces of various markets.
I use Windows Terminal quite often and have definitely noticed its terrible performance. So this is definitely something visible in the real world and not just nitpicking.
> Microsoft is a faceless entity composed of people who mostly don't care about what they do during the day and are just getting by so they can get paid.
Regardless of what you think about Microsoft the company, please remember that the individual workers and managers are people who can be hurt by our tendency to form self-righteous mobs. And according to another commenter [1], one of the people working on Windows Terminal was hurt to the point that they quit.
Full disclosure: I'm inclined to defend the Microsoft team here because I was at Microsoft (on the Windows accessibility team) for a while. I don't think that I or my former teammates fit the stereotype you described. And while I never met any of the developers on the Windows Terminal team (at least not knowingly), I could very easily have crossed paths with one of them; I believe my team used to be in the same building as theirs. So I'm inclined to be charitable.
This might get me some shit but running away like that isn't a good trait to have. Not for Microsoft, but also not for themselves. This will probably be in the back of their mind for a chunk of their career since they have no closure.
I would expect somebody working on a greenfield project at one of the biggest software companies in the world to tackle issues head on with grace.
Those individual workers hurt the project and the community around it by setting the precedent that you need to create your own competing product to verify that bugs can be fixed without PhD research.
Nobody should be harassed over their open source project, but that doesn't mean actions don't trigger reactions.
inexperienced developers are unable - or just rarely - ask themselves the question:
"is the current performance in the right ballpark of where it should be?"
here it's obvious - muratori took one look at that thing and just knew that "no, 2-3 fps is definitely, completely off". i, too, had a couple of those moments where i got my hands on some code and thought: "that just can't be right" and then found O² algorithms, byte-by-byte io copy routines, database abuse or duplicated work.
if you don't have the rough reference points of what should be right, you often just don't question correctly working code.
In my experience, basic coding skills can really atrophy in senior developers who quit writing code years ago and are full-time architects/managers.
I’ve interviewed more than a handful of extremely accomplished people with decades of experience as developers and then engineering managers who couldn’t answer extremely basic coding questions (we’re talking “efficiently find duplicates in a list” or “compute Fibonacci numbers” basic). These people never could get past the O(n^2) brute force solution for finding duplicates (or the brute force compute every Fibonacci number starting from 1, 1), because they hadn’t thought about even basic algorithmic complexity in so long. And when people like this are giving orders from the top, you can see how software can get so slow.
I have no doubt that when these people were actually still coding, they could have answered my questions in their sleep. Quitting coding for engineering management really does one a disservice IMO. To this article’s point, I’ve also had the pleasure of working with people with decades of experience who never quit coding even as senior managers and their level of competence and productivity is astounding.
I really cannot fathom how one could forget fundamentals.
I can prove the average complexity of quicksort with simple math transformations of initial recurrence equation which I do not even have remembered but I'm sure I could derive. Last time I did this was maybe 8 years ago if not more.
Yet somehow an accomplished dev cannot spot accidentally quadratic behavior when coding in something that is not Haskell.
IMO, the average dev and average accomplished dev is no longer the kind that knows the fundamentals. Not that it's necessary in all cases but eventually everything will look an equivalent of a doctoral thesis when the average codes the spaghetti mess.
Recently I was reviewing code with map(find).sort(indexOf) (O(n^2 log n + n^2) behavior) when it could have been a simple dict; map(dict.get) (O(n)). This person has 10 years of coding experience. When looking at the resume, the dev is pretty accomplished, productive, and worthy of the salary. But I assume the knowledge of fundamentals was missing from the start.
PhDs often make the worst possible developers. People with PhDs (especially in Mathematics) are often lacking the most critical characteristic of a good developer; they don't know why they do things. Being good at math requires being able to solve problems whose solutions often do not have any practical uses or whose practical uses may not be clear. This is very different from how software problems should be approached. Software development is more about finding the right problems than it is about solving problems; to find the right problems, you need to understand the 'why' in as much detail as possible. Every line of code should be easily justified by how it brings the system closer to achieve its purpose. The PhD diploma itself doesn't have much practical use in financial terms; it's not a good investment to get a PhD for purely practical reasons. Detatchment from practicality is the worst attribute someone can have as a developer.
> Software development is more about finding the right problems than it is about solving problems; to find the right problems, you need to understand the 'why' in as much detail as possible.
This is what a software or CS PhD makes you understand. You know the why's to the lowest level possible.
> The PhD diploma itself doesn't have much practical use in financial terms; it's not a good investment to get a PhD for purely practical reasons. Detatchment from practicality is the worst attribute someone can have as a developer.
In my experience it's the opposite. After I got mine, I realized that I can answer these "Why"s faster, infer my own knowledge and can write better code easier and in less time. The whole process got much entertaining too.
I say, it doesnt matter, PhD or no PhD. Alot of the smartest people in the world have no PhD.
What i will say is that, i suspect PhD people to be people that create more theories around how to solve certain problems. And this. is very very very bad. It leads to design patters and generic solutions aka. lazy solutions that are just bloated and slow.
And this is a problem i see often with people who learned to code via school/university or some code academy like BS.
Design patterns are evil, and solutions should always be custom made towards the problem and be made as simple as possible. Only then you wont end up like microsoft or 95% of all developers.
> Being good at math requires being able to solve problems whose solutions often do not have any practical uses or whose practical uses may not be clear to you. This is very different from how software problems should be approached.
I don't really agree. Being good at mathematical research requires recognizing the "core organization structure of a system" and solving the "core problem at hand". I'd argue that it's essentially the same in programming (and business) as well. The main difference is that a mathematical researcher is able to ignore non-pertinent information, while in practice those issues (usually) need to be dealt with.
That said I wouldn't say that PhDs (math or otherwise) make great developers. Their skill in development is a result of experience in developing software within the software industry and not something they gain simply due to "being intelligent" or by working on their on on their POC research implementations. But I'd point out that it's basically the same for professional software developers as well.
However, there are probably infinite organization structures describing a complex system and there isn't any ontological reality to Occam's razor. Programming is really much about deciding where and at what level to allocate partial structure, which again informs the broader picture of the core organization – and some of this may be even intuitive.
A bit if a generalisation. For a different view: currently almost all the core devs for NumPy and SciPy (those are the ones I know personally) have doctorates.
I think that we can agree that if you want to become a generalist programmer, able to hop from random web startup to random web startup, then a PhD is probably not that useful. If however you want to become more of specialist, say being able to develop novel solutions to complex fluid dynamics problems then a PhD is very useful place to start.
I have a PhD (physics), and I worked in a quant team with maths, physics, engineering and comp sci PhDs, and I can assure you the bell curve demographic is identical there as it is in a department of non PhDs. There are some very good developers, the odd mythical "10x" developer (in this case, someone that really just writes repeatedly same thing in every job to be honest), and some very poor developers.
> The PhD diploma itself doesn't have much practical use in financial terms; it's not a good investment to get a PhD for purely practical reasons.
I don't know if you say this because you have don't have one, or haven't worked with many (not just one) PhDs?
In the UK at least, your starting salary will be significantly higher than just a plain degree, and it also opens up a broader job market (in the City, at least, and aerospace and defense) where PhDs can be a requirement in some jobs because (junk) degrees are now ten-a-penny.
You learn writing skills, and analytical skills both of which are financially useful and practical.
I get the feel that what you're implying is that PhDs are less imaginative and perhaps less likely to be entrepreneurial. In that case, you may have a point.
My point is that, on average, in my experience, they are more interested in big complex theories and hypotheticals than in reality and all its tedious subtleties. They can miss the point that all these tedious subtleties add up in terms of complexity and shouldn't be scoffed at.
This infatuation with complexity is itself a big problem. I've observed a lot of PhDs neglect the cost of complexity. Choosing complex solutions with significant practical drawbacks over simpler ones in order to get some tiny gains in performance (for example) or to get some specific characteristics which they feel is important but which the average user doesn't care about at all.
I find this generalization a bit hard to believe. Good academic researchers should be obsessed with knowing why they do things. After all, researching the state of the art and identifying a knowledge gap is what they do. And they should also be quite good at documenting the how since they write a lot of methods sections.
Maybe not in mathematics as I have no idea what a math PhD thesis looks like but for all other fields I know I'd expect a good researcher to be exceptionally good at giving a reasoning for why they do something and also at knowing what other approaches were tried by other people and what the pros and cons are.
But I find the comparison PhD vs. developer a bit unfair. I agree that you become a better developer if you develop for 4 years instead of doing a PhD. Even in CS, a PhD entails many things that are not developing, namely writing papers, getting grant money, teaching etc.
However, I also agree with you that if the goal is to become a better programmer, a PhD is not the way to get there (imo).
If you're hiring a PhD Mathematician and expecting them to be great developers, then you're quite frankly doing it wrong. Don't get me wrong there are great developers with a PhD in mathematics, but that's got nothing to with their PhD (in general). You hire a PhD mathematician because you have math problems relative to their expertise that you need solving, and if they're not great programmers you pair them with a great programmer to help implement their solutions.
cmuratori is great software engineer, for sure, but, god, this bug report poisons the well right from the start (see below).
Also the report is actually quite bad, because 40x performance drop, that is stated, could be actually nothing. If something takes 1 millisecond instead of 25 microseconds (numbers from the head, to illustrate the point), it might be an issue, but also might mean nothing. This is the thing that requires clarification, from my pov.
Regarding poisoning the well: instead of writing
"
Expected Behavior
Despite the increased parsing load, modern CPUs should not have a problem parsing per-character color escape codes quickly. I would expect the performance of the terminal to be able to sustain roughly the same frame rate with per-character color codes as without, and if there was a performance drop, I wouldn't expect it to be anything close to 40x.
"
he could just write
Expected behavior
Frame rate of output with per-char color codes is similar to non-colored output.
And that is why I'm saying that initial bug report could be done better.
For example, out of curiosity I did the test from the last message: doing "cat big.txt" in WSL2. In Windows terminal it took 1.5s, but in Kitty terminal, that is running under wslg (same ubuntu version), it takes 0.34s. Powershell, from the other side, is awful (20-25s).
I personally disagree. I don't see any poisoning in the original bug report; furthermore, I think it conveys the issue (and some of its subtleties, such as referencing "modern CPUs") much more clearly than the version you propose.
Agree, pretty unfriendly tone. I would expect from a more senior developer that he or she has a high enough social intelligence to understand how to confront others with their findings in a clear but friendly way.
Whether this is interpreted as unfriendly depends on the stance of the reader. I can easily make this sound somewhere between "celebratory" or "intriguing" when I read it. If I were the author and performance/bug-reports somehow meant negative consequences for me, then it would sound hostile.
> Due to the way the programmer’s ranking system works, an average company will have a big crowd of inexperienced people and very few who can tackle complex problems. For this reason, the vast majority of software is written by the ones who are still learning the ropes.
I wonder if another reason is just that it’s such a growing industry. The number of CS grads each year are growing, and I know tons of people who sidestepped into the profession from other degrees as well. The number of jobs too. If the job market is twice the size it was a decade ago, half the employees are going to be new no matter what. Perhaps hilariously, that huge demand means high wages, means more early retirements, means fewer senior people too.
> it seems to me that the software industry doesn’t value technical excellence as much as it values having warm bodies report to you
Naturally. Computers don't pay, these wet bodies pay progressively for values they perceive. Technology is merely an instrument to add amounts of currency value to products that it is to hold. Also, a business that relies on technical excellence of small groups of individuals is not a business well conceived.
Logical complexity impregnated into an artifact, logical or physical, is a completely separate phenomenon to currency values it holds within the system of human economy. Took me way too long to get it. The fact that the two are considered same is itself probably something worth discussions.
I tihnk I generally agree with this, but also wonder what the alternative is.
If you step outside your own industry, do you want plumbers that have a hobbiest appreciation of the intricacies of fluid dynamics, or do you want someone to come and unblock your toilet in the middle of the night?
There's possibly a middle ground where the geniuses invent toilet technology in such a way that it is easy to install and maintain, and "normal" people do all the other boring bits, like stocking warehouses, transporting it, selling the house it sits in, answering the phone etc. It feels like we've generally got there in both plumbing and in software and is that a bad thing overall?
I just want Microsoft to develop a proper terminal application and not handwave away complaints about performance with "that's a PhD right there". Even if it was a PhD, I'd then expect a PhD to be put to the task, because this is a crucial component of the operating system.
Realistically though, a PhD is the opposite of what you want here. A PhD is almost by definition an inexperienced programmer. It's also someone who is likely to fall in love with their ideas, putting aesthetics or purity above practicality and effectiveness.
I was more responding to the article, which used that specific example as a jumping off point to talk about management structure in software development generally.
I don't use Windows, but I do use Kitty terminal (https://sw.kovidgoyal.net/kitty/) and from my interactions with that project and trying to get code ligatures working in my setup I've learned that terminals are really complex, both for technical and legacy/ecosystem reasons so my gut reaction is to support the MS engineers, without having read deeply into that specific issue.
edit: having read some more of the original ticket, I'm more firmly on the MS developers side. I think the other person is both rude and uninformed about what they are talking about, which is a terrible combination.
This would be a nice thesis. Unfortunately we have software like memcached, redis, nginx, Envoy, Kafka, Zookeeper, and more that come straight from professional programmers which makes this thesis more complicated than this post makes it sound. Perhaps Occam's Razor should apply here.
That software from a pool of millions of SWE across the world. And importantly this software created outside of corporate structures! I think these exceptions prove the rule.
Most SWE are working for companies that don’t make money reinventing architecture. Leading a bunch of people to use existing tools to sell something to customers is probably where most of the value comes from in SME world and probably most of the big company world too.
Everywhere I have worked the very experienced people are probably doing the “the same year repeated many times” rather than a pyramid of experience taking on more complex engineering challenges.
At one of my previous companies they hired two engineers specifically for performance. They were sharp guys. Problem was, they were put on their own team/silo and basically no one involved them in any of the work. Their PRs were considered more of an unpleasant intrusion into other peoples sprints. They became useless because of the terrible organization! Total wasted talent because "performance" was an afterthought in every respect.
It's just that in corporate world, developers rarely do what they think is relevant for them.
The people who did Windows terminal probably cared a lot about COM or WinAPI or maybe CS, but I think it's fair to imagine how they were not fans of text-oriented interfaces. It just did not occur that they should be extracting last bit of performance here. People can type just that fast, after all.
TBF we've actually maintained the Windows Console for the better part of 5 years and we're incredibly passionate about performance. We live and breath in the commandline. Performance has always been one of our P1 priorities, because improvements to the console have second-order impacts on the entire commandline ecosystem.
There is an engineering tradeoff though - we've only got so many devs and at a certain point you have to say "good enough for now, we'll come back to this, let's go do this other thing for now". The Terminal is faster than conhost was, and that's a good place to start, but I don't think anyone things we're done working on the Terminal, and we're certainly not done working on its perf ;)
Windows terminal is a shit show. The dev blogs posts are all about useless features such as image background while fundamentals like unicode input are still broken.
My mouse would start lagging whenever I “moused” over an active Windows terminal window, in spite of running a brand new system with a 3070 GPU etc. Did they ever manage to fix that?
Like Windows Notepad. I suspect it was never designed for anything more than trivial cases, and then it never got requirements overhaul later in subsequent versions of Windows.
I think a significant contributing factor is that management is a local maximum.
I am a self-identified "sort of knows what they are doing" (albeit, sometimes insecure about that) professional programmer. I've also had the chance to take a leadership position. So, I think I have a useful perspective here.
The amount "I" can accomplish in a leadership position is so much higher than by coding directly. So, on the margins, it's really hard to justify time spent coding, compared to coordinating others. It's incredibly easy to imagine stagnating as a coder due to not doing very much of it. Yet, clearly when everyone follows this route, software quality suffers. I don't have any particular solutions.
Perhaps eventually the rate of expansion of programmers will slow, and we'll end up with too many sort of knows what they're doing" programmers for everyone to move to management, so people/companies will start waiting until programmers hit the experienced mark to make the leap.
Maybe everyone needs their ansi.sys moment though. Back in the early 1990's, I, and probably half the programmers using DOS, rewrote the dos ansi.sys driver/TSR because its was _SLOW_. mostly IIRC because it was calling the BIOS text output, but also because it was a pretty solid implementation of the ANSI terminal/esc sequence "standard".
So, the first half took about an hour or two to handle output (just write a character at the right location in the framebuffer) and get the INT/TSR boilerplate right. Then for the next 20 hours fight with all the edge cases the cropped up with corrupted text in various TUI programs that were calling the DOS string functions. Then as the size+perf approached NANSI.sys (http://www.kegel.com/nansi/) give up...
> Based on my limited anecdotal evidence, it seems to me that the software industry doesn’t value technical excellence as much as it values having warm bodies report to you. This in turn limits the amount of experience an average programmer working on these big projects will have, just because they are incentivized to leave the hands on implementation work for some sort of a leadership role as soon as possible.
+10000. This is so true. It's not just that people are incentivized to leave hands-on work. Every level of the management genuinely believe that a senior engineer should not spend much time on hands-on work but instead should focus on "tech leadership", which in a big company means going to meetings, influencing other teams, writing white papers, and of course "coordinating".
From the linked article itself, I can attest to the constant push to move up into 'leadership' roles, particularly in some companies. I have stayed and worked as an engineer for 37 years. I have been 'team lead' a half dozen times, but never a full manager role. Why? Because I would be a poor manager. I have personally experienced managers that where technically brilliant, but not good at managing (or inspiring) the technical staff. They should have remained as engineers/scientists. Some corporations used to have parallel paths for technical staff that had management level pay and benefits, but the suits in the 'C suite' have eliminated that for the most part over the last twenty years. Bell Laboratories (now a shell of its former self) was once one of those places.
So in the current environment, there is constant pressure to move up or move out. Even startups are no longer immune to that. If you want to have enough shares for it to really matter in a liquidity event, you need to have a team of people below you, or at least a director level title. The startup environment in 2000 was completely different, and technically astute engineers (mechanical, electrical, software) could attract strong stock grants as engineers. That has changed. I am fortunate in that after 37 years of doing this, I am at a position where I don't even have to think about these issues any longer. I feel sorry for younger engineers breaking into the field, the management pyramid is such a PITA.
And back to the topic of strong technical engineers that are poor managers? If you get stuck into one of those situations, constant micro management, constant downward pressure of "you don't know what you are doing", get out. Find a new position elsewhere. Good managers will coach you when you need help, but will let you do your own work. Good managers will help identify your deficiencies but also guide you to work that plays to your strengths. Good managers will provide you opportunity for growth. I learned this early in my career, blessed with having an awesome manager. Since then, every job I have had, first thing I did was figure out which managers were good, and which ones were not, and made sure that I never had to work under a bad manager.
So you can make a career in engineering, but it has to be a choice, and you have to learn to manage your managers.
Also note, while I recognize that I would be a poor manager (for various reasons), mentoring is a different skill set. If you are a senior engineer, take every opportunity to mentor a starter in the field.
This seems like giving up. The article is right about the problems but seems temperamentally opposed to actually fixing them. Number of people under you is a terrible metric in many ways, but it is at least objective (ish) and hard to fake; so is years of experience. If you take the position that programming skill requires years of particular kinds of learning and there is no way to assess whether someone with x years on their CV has actually done y years of that kind of learning... well, maybe that's true, but what's the actionable takeaway from that?
I don't disagree. That said, the first step in solving a problem is to understand that there is one and what are its root causes.
EDIT: I think sometimes to goal of some prose is to be thought provoking, i.e. to allow us to find somebody else who perhaps will find a better solution if only they had been stimulated enough to care about a problem
When you interview a line manager and he boasts that he led a team of 100 engineers, do you question that he could have done the job with 10 better-picked engineers?
You get what you measure. If you reward bloat, you get train wrecks.
Hm... It's totally okay, to not be able to do it. Nobody can know everything. Doesn't mean you are in a "lower" category compared to your colleagues.
Okay, it's not a global problem (ie. "needs PHD") but just a personal problem (ie. "I have no clue how to solve it"). Trying to get as much stuff done as possible, I've said similar things in the past, though. Not really thought about it before typing. Happens...
Nobody got hurt in the process, right? Let's forgive this little misinterpretation and move on.
Nobody here seems to be focused on the specifics of the case. But i think moving on would leave a great opportunity to re-evaluate corporate SE choices.
At the very least we can agree its a good thing that the dev was able to fork/re-implement the tool with the given API.
But for me it raises the larger question.
How useful is this form of software engineering management?
The tool is relativity simple enough to re-implement ( Which is a good thing ), but at the same time an entire team/governance structure was put in place to act out a set of motions, without pushing what is possible.
To be blunt, it sounds miserable to have to work like that.
> the software industry doesn’t value technical excellence as much as it values having warm bodies report to you.
One of those can easily and objectively be measured, and the other one can't.
Various orgs have tried to measure financial "value", imperfect in and of itself, but then face serious problems attributing that to individual developers.
Fundamentally, discussing "good" software is performing subjective evaluations against subjective criteria. There's no easy route out of that.
The problem with the excuse parade is, that it has to justify itself. They have to be special, the avant-garde, selected through countless interviews to live well inside the castle. If some wandering apprentice can outperform them, the hot air escape from the "rockstar" developer, wrestling with complex code sitting inside the compound of a FAMG firm.
Then nothing remains, but embarrassed silence.
And the question, why this people are paid for, if they waste the customers money, aka performance of the customers computational platform and the outcome is so sub-par.
Which is why they are sitting all in one huge meeting today.
I work as a mining engineer and in my eyes these stages are effectively the same as the author describes in the software world. I'd even argue they apply to most "professional" careers.
I remember a post Msoft Dev wrote about adding a fairly simple feature to a web api. The code itself could be written by a single dev in a day or two, but the logistics needed for testing, documenting, supporting and communicating this involved hundreds of people with thousands of man hours. It also would bind them to maintaining this feature almost indefinitely. Because of that last point alone it took months to years to get a signoff on features.
Most of the industry seems structured to keep devs at an intermediate level: resume-driven hiring, ageism, proliferation of open source that prioritizes easy over simple, little discussion of software design, complete lack of education/resources to move devs past that, and incentives that push people into management.
Another thing I realized when writing this: where do experienced devs congregate? (It isn't Twitter.)
> A few hours later another programmer came up with the prototype of a much faster terminal renderer, proving that for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking.
I read through the Github issue and can't find the prototype mentioned here. Can anyone link the PR/code if they know it please?
Whatever the comments from both Microsoft and Casey Muratori about particular details of their implementations, Windows lacks a terminal like Linux Kitty (there's an unrelated Kitty that's just a fork of PuTTY).
And by that I mean speed and features. Kitty is fast and a joy to use, and it is the software I miss the most when I am using Windows.
I noticed that when you propose a new idea, often there is no shortage of resident "experts" giving you hand-wavy reasons as to why it can't work, won't work, etc. I kind of feel like you DO need a PhD just to have enough clout for these kinds of people to trust you.
My company hired a number of PhDs. They were all smart and well educated but for some reason couldn’t turn that knowledge into working software. So they were all fired in less that a year.
fwiw, file system access is kind of a bad example - it's slow because the design allows people to hook into it. once you've made promises to end users that limits the kinds of optimizations you can do and how far you can go with those optimizations.
For one example, if you were to make file I/O bypass antivirus software in 'performance sensitive cases', few enterprise admins would accept that. That performance optimization would be disabled in a millisecond. You can do directory exclusions, but some of the I/O still has to go through the filter to be checked against the exclusion list.
There are a couple claims/assumptions in the article that feel weird to me.
1. The article derides those using "years of experience as some sort of a badge of knowledge", yet keeps on referring to "experienced" programmers as if they were better. Maybe it's terminology, but in my experience (no pun intended) there's no useful correlation between the time one is writing software and their ability to tackle hard problems. "Experience" seem to matter much less than talent, imagination and passion.
2. Article says "Sitting in an office and shuffling papers around for a decade doesn’t make you a master programmer. Writing software does." -- writing software for a decade really doesn't automatically make somebody a master programmer. The author states elsewhere in the article: "I believe your self interest and curiosity matter more than the years spent writing getters and setters". So, which one is true? As mentioned in the previous point, I tend to think the latter.
3. The article mentions "the vast majority of software is written by the ones who are still learning the ropes" as if it were a bad thing. It really isn't, in fact this is the only way people can get "experience" in a growing industry where junior devs outnumber senior devs simply due to how large the industry has grown over the past ~40 years. It has everything to do with exponential growth in the software industry and has nothing to do with programmers going into middle management and leadership roles.
4. To make sure software is competently written even if most of them are written by junior devs, the managers/leads have to make sure everybody is assigned tasks that they can handle, perhaps with supervision by a more senior/skilled dev. The job for the tech lead is to figure out which is which, and ensure that the critical parts are competently dealt with by appropriately skilled people. This is a skill that requires competence and experience. Unless you have an endless supply of senior devs, you definitely want to "distract" the senior developers from their implementation work and put them in charge of this work.
5. Article says "the experienced programmers will take care of the design problems, but that is not going to save your bacon if the implementation of a great design is terrible." -- this is of course true if you have a team of truly terrible programmers, but not necessarily true if they are just "mediocre". Design decisions include choice of language and architecture (and sometimes process), and some demand more of the developers than others. There are ways to isolate bad implementation with clean(ish) interfaces, so that "big ball of complicated code" becomes small balls of bad code that can be fixed up bit by bit.
6. This is one of the most confused claims in the article: "If you want to produce a high quality software, you also need enough experienced people in the trenches that are not merely delegating the orders from the ivory tower." The only way this can work is if you only hire "experienced" people and reject all junior devs. Because in the author's ideal world there's really no place for junior devs. They can't be mentored because that will distract "experienced programmers" from the real work in the trenches. They can't be groomed for management roles because then they can't become "experienced programmers". It really sounds like to me that the author doesn't really know how to properly manage junior devs in a team and simply assumes that if "experienced programmers" who have kept writing software in the trenches were able to keep writing software, then the result would automagically not suck. I don't think the real world works that way, not until the software industry collapses and only the best programmers are able to keep being employed.
In all it feels like the author was trying to sound insightful by stringing together a story that, at best, is just pointing out that "experienced programmers" are better than "wet behind the ears" without providing a suggested solution, and at worst, making up superficial narratives that doesn't really hold up when you try to poke it.
Sure, for every senior dev taking on management or mentoring duties, the team loses out some quality man-hours on coding, but that is presumably a positive trade overall, or people would stop doing that. The only way to keep "experienced programmers" focused on coding are: don't hire junior devs, don't mentor junior devs and don't let technical staff enter management. I'm pretty sure that's not what the author tried to say, and unless I'm missing some obvious solution pointed out somewhere, the whole point of the article seems to be spinning a flamewar from github into a sentimental narrative that doesn't lead to any conclusions..
Such an interesting case. We need to encourage respectfully disagreeable people like the developer who raised this issue. A less disagreeable person would have stopped pushing after receiving the GitHub feedback regarding how complex the problem was.
It's a shame that engineers commit their time for free for the benefit of multi billion corporation. Why do they do it?
These corporations are not your friends.
Puzzles me. It’s ironic you give stuff away as “free software” for “the masses”, you are just helping the Pandora papers mob get richer. Unless that software is genuinely disruptive. Tor, BitTorrent for example. But that’s more rate. Memcached, Redis being free just helps corporations really.
On the one hand you have idealists who think the most important thing in the world is getting the last bit of performance out of every program. On the other side you have businesses who don't care too much about performance of their applications (especially when no money can be made out of it) as long as 80% of use cases are covered.
Whichever side you sympathize with, it's pretty arrogant to think the other side is completely wrong.
A few hours later another programmer came up with the prototype of a much faster terminal renderer, proving that for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking.
I have no idea if this is the case here, and I suspect it might not be, but pretty much every time I've seen a developer complain that something is slow and then 'prove' that it can be faster by making a proof-of-concept the only reason theirs is faster is because it doesn't implement the important-but-slow bits and it ignores most of the edge cases. You shouldn't automatically assume something is actually bad just because someone shows a better proof-of-concept 'alternative'. They may have just ignored half the stuff it needs to do.
This particular case was discussed at length on Reddit and on YC News. The general consensus was that the Microsoft developers simply didn't have performance in the vocabulary, and couldn't fathom it being a solvable problem despite having a trivial scenario on their hands with no complexity to it at all.
The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] and was more correct than the Windows Terminal!
RefTerm 2 vs Windows Terminal in action: https://news.ycombinator.com/item?id=27775268
[1] Features relevant to the debate at any rate, which was that it is possible to write a high-performance terminal renderer that also correctly renders Unicode. He didn't implement a lot of non-rendering features, but those are beside the point.
And the experienced developer is Casey Muratori who is somewhat well known for being a very experienced developer. That makes it less likely that he doesn't know what he's talking about and is skipping over hard/slow features.
80 replies →
I found it very funny that the Hindi sample text on display, in the YouTube refterm demo, means “You can wake up someone who is sleeping, but how do wake up someone who is hell bent on pretending to sleep?”.
A bit out of topic but has anybody followed performance issues of Microsoft Flight Simulator 2020? For more than half a year it was struggling with performance because it was CPU heavy, only loading one core and etc. Barely ran on my i5 6500. Fast forward half a year, they want to release it on XBox. MS/Asobo moves a lot of computation on GPU, game starts running smoothly on the very same i5 with maximized quality settings.
You just begin to wonder how these things happen. You would think top programmers work at these companies. Why would they not start with the good concept, loading GPU first etc. Why did it take them so much time to finally do it correctly. Why waste time not doing it at the beginning.
17 replies →
Sometimes you don't know you have a performance problem until you have something to compare it to.
Microsoft's greatest technical own goal of the 2010s was WSL 2.
The original WSL was great in most respects (authentic to how Windows works; just as Windows NT has a "Windows 95" personality, Windows NT can have a "Linux" personality) but had the problem that filesystem access went through the Windows filesystem interface.
The Windows filesystem interface is a lot slower for metadata operations (e.g. small files) than the Linux filesystem interface and is unreformable because the problem is the design of the internal API and the model for security checking.
Nobody really complained that metadata operations in Windows was slow, they just worked around it. Some people though were doing complex build procedures inside WSL (build a Linux Kernel) and it was clear then there was a performance problem relative to Linux.
For whatever reason, Microsoft decided this was unacceptable, so they came out with WSL 2 which got them solidly into Kryptonite territory. They took something which third party vendors could do perfectly well (install Ubuntu in a VM) and screwed it up like only Microsoft can (attempt to install it through the Windows Store, closely couple it to Windows so it almost works, depend on legitimacy based on "it's from Microsoft" as opposed to "it works", ...)
Had Microsoft just accepted that metadata operations were a little bit slow, most WSL users would have accepted it, the ones who couldn't would run Ubuntu in a VM.
3 replies →
What's wrong with the performance? I don't notice any performance issues in Windows terminal.
4 replies →
I just launched "dir"
https://i.imgur.com/lkbOR3i.png
can't even print properly the decimal separator.
maybe it wasn't that easy.
51 replies →
A pretty one sided view. I use Windows terminal because it supports multiple tabs - multiple cmds and some WSL bashes.
I don't care at all if this or that terminal uses a bit more RAM or is a few milliseconds faster.
2 replies →
> The "complaining developer" produced a proof of concept in just two weekends...
That developer also was rather brusque in the github issue and could use a bit more humility and emotional intelligence. Which, by the way, isn't on the OP blog post's chart of a "programmers lifecycle". The same could be said of the MS side.
Instead of both sides asserting (or "proving") that they're "right" could they not have collaborated to put together an improvement in Windows Terminal? Wouldn't that have been better for everyone?
FWIW, I do use windows terminal and it's "fine". Much better than the old one (conhost?).
5 replies →
That sounds like you've never seen performance of a heavily worked-on subsystem increase by 10x because one guy who was good at that kind of stuff spent a day or two focused on the problem.
I've seen that happen at least 10 times over my career, including at very big companies with very bright people writing the code. I've been that guy. There are always these sorts of opportunities in all but the most heavily optimized codebases, most teams either a) just don't have the right people to find them, or b) have too much other shit that's on fire to let anyone except a newbie look at stuff like performance.
More generally, in my experience performance isn't looked at because it's "good enough" from a product point of view.
"Yes it's kinda slow, but not enough so customers leave so who cares." Performance only becomes a priority when it's so bad customers complain loudly about it and churn because of it.
5 replies →
I've made such optimizations and others made them in my code, so:
c) slow code happens to everyone, sometimes you need fresh pair of eyes.
2 replies →
I’ve seen it at least as many times, too. Most of the time, the optimization is pretty obvious. Adding an index to a query, or using basic dynamic programming techniques, or changing data structures to optimize a loop’s lookups.
I can’t think of a counter example, actually (where a brutally slow system I was working on wasn’t fairly easily optimized into adequate performance).
3 replies →
I don't know about you, but I was really laughing out loud reading that GitHub conversation.
GPUs: able to render millions of triangles with complex geometrical transformations and non-trivial per-pixel programs in real time
MS engineers: drawing colored text is SLOW, what do you expect
P.S. And yes, I know, text rendering is a non-trivial problem. But it is a largely solved problem. We have text editors that can render huge files with real-time syntax highlighting, browsers that can quickly layout much more complex text, and, obviously Linux and Mac terminal emulators that somehow have no issue whatsoever rendering large amount of colored text.
To be fair to the MS engineers, from their background experience with things like DirectText, they would have an ingrained rule-of-thumb that text is slow.
That's because it is slow in the most general case: If you have to support arbitrary effects, transformations, ligatures, subpixel hinting, and smooth animations simultaneously, there's no quick and simple approach.
The Windows Terminal is a special case that doesn't have all of those features: No animation and no arbitrary transforms dramatically simplifies things. Having a constant font size helps a lot with caching. The regularity of the fixed-width font grid placement eliminates kerning and any code path that deals with subpixel level hinting or alignment. Etc...
It really is a simple problem: it's a grid of rectangles with a little sprite on each one.
3 replies →
It's more subtle than that. What the Microsoft engineers are saying is that the console's current approach to drawing text is inherently slow in this particular case, due to the way the text drawing library it's based on uses the GPU. The proposed solution requires the terminal to have its own text drawing code specific to the task of rendering a terminal, including handling all the nasty subtlties and edge-cases of Unicode, which must be maintained forever. This is not trivial at all; every piece of code ever written to handle this seems to end up having endless subtle bugs involving weird edge-cases (remember all those stories about character strings that crash iPhones and other devices - and the open source equivalents are no better). It's relatively easy to write one that seems to work for the cases that happen to be tested by the developer, but that's only a tiny part of the work.
1 reply →
Simply shaping text using state of the art libraries (like harfbuzz) can take an INCREDIBLE amount of time in some cases. If you're used to rendering text in western character sets you may think it can always be fast, but there are cases where it's actually quite slow! You get a sense for this if you try to write something like a web browser or a word processor and have to support people other than github posters.
Of course in this case it seems like it was possible to make it very fast, but people who think proper text rendering is naturally going to be somewhat slow aren't always wrong.
Saying that text rendering is "largely solved" is also incorrect. There are still changes and improvements being made to the state of the art and there are still unhappy users who don't get good text rendering and layout in their favorite applications when using a language other than English.
4 replies →
I understand the scepticism about such claims, but Casey's renderer is not a toy, and handles a number of quite dificult test-cases correctly. He solicited feedback from a sizeable community to try and break his implementation. The code is vailable here: https://github.com/cmuratori/refterm
From the refterm README:
refterm is designed to support several features, just to ensure that no shortcuts have been taken in the design of the renderer. As such, refterm supports:
* Multicolor fonts
* All of Unicode, including combining characters and right-to-left text like Arabic Glyphs that can take up several cells
* Line wrapping
* Reflowing line wrapping on terminal resize
* Large scrollback buffer
* VT codes for setting colors and cursor positions, as well as strikethrough, underline, blink, reverse video, etc.
The really hard part of writing a terminal emulator, at least from my experience working on Alacritty, is fast scrolling with fixed regions (think vim).
Plently of other parts of terminal emulators are tricky to implement performantly, ligatures are one Alacritty hasn't got yet.
1 reply →
Reading the thread itself, it’s a bit of both. Windows Terminal is complex, ClearType is complex and Unicode rendering is complex. That said… https://github.com/cmuratori/refterm does exist, does not support ClearType, but does claim to fully support Unicode. Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2 and (b) it sounds like the Windows Terminal project is indeed a bit more complicated than can be hacked on over a weekend and would need extensive refactoring to support the approach. So it sounds a bit more like a brownfield problem than simply ignoring half the things it needs to do, though it probably does that too.
> Unfortunately, Microsoft can’t use the code
As good as Casey Muratori is, Microsoft is more than big enough to have the means of taking his core ideas and implement them themselves. It may not take them a couple weekends, but they should be able to spend a couple experienced man-months over this.
The fact they don't can only mean they don't care. Maybe the people at Microsoft care, but clearly the organisation as a whole as other priorities.
Besides, this is not the first time I've seen Casey complain about performance in a Microsoft product. Last time it was about boot times for Visual Studio, which he does to debug code. While reporting performance problems was possible, the form only had "less than 10s" as the shortest boot time you could tick. Clearly, they considered that if VS booted in 9 seconds or less, you don't have a performance problem at all.
> Unfortunately, Microsoft can’t use the code
I commented on a separate issue re: refterm
--- start quote ---
Something tells me that the half-a-dozen to a dozen of Microsoft developers working on Windows terminal:
- could go ahead an do the same "doctoral research" that Casey Muratori did and retrace his steps
- could pool together their not insignificant salaries and hire Casey as a consultant
- ask their managers and let Microsoft spend some of those 15.5 billion dollars of net income on hiring someone like Casey who knows what they are doing
--- end quote ---
> Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2
One thing to remember is that it is always possible and acceptable to contact the author of a GPL-licensed piece of code to enquire whether they would consider granting you a commercial license.
It may not be worthwhile but if you find exactly what you're looking for and that would take you months to develop yourself then it may very well be.
7 replies →
> (a) it’s GPLv2
Why is that a problem? A GPLv2 terminal would not be a business problem for Microsoft. People would still have to buy licenses for Windows. Maybe they would lose a little face, but arguably they have already done so.
At least it’s not GPLv3 which this industry absolutely and viscerally hates (despite having no problem Apache 2.0 for some reason, Theo de Raadt is at least consistent).
3 replies →
> Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2
That's not unfortunate. Having people who work on competing Free Software is a good thing. It would be even better if Microsoft adopted this code and complied with the terms of the GPL license. Then we won't have to deal with problems like these because they'd be nipped in the bud. And we would set the precedent to take care of lot of other problems like the malware, telemetry, abuse of users' freedoms.
It's the hardest thing about building perf-related PoCs. Every time I've built a prototype to prove out an optimization, I've spent the entire duration of the project watching the benefit shrink, stressing that it would dwindle to nothing by the end. So far, I've been lucky and careful enough that I haven't convinced a team to expend massive resources on a benefit that turned out to be fictional, but I've had it happen enough times at the scale of a p-day or two that it always worries me.
Counterexample: WireGuard. Turns out OpenVPN was massive and slow for no reason and it only took one (talented and motivated) man to make a much better version.
> > for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking.
> You shouldn't automatically assume something is actually bad just because someone shows a [vastly] better proof-of-concept 'alternative'.
Apparently you should. I can confirm that the first quote is a appropriate assessment of the difficulty of writing terminal renderer. Citation: I did pretty much exactly the same thing for pretty much exactly the same reasons when (IIRC gnome-)terminal was incapable of handing 80*24*60 = 115200 esc-[-m sequences per second, and am still using the resulting terminal emulator as a daily driver years later.
>> I have no idea if this is the case here, and I suspect it might not be, but pretty much every time I've seen a developer complain that something is slow and then 'prove' that it can be faster by making a proof-of-concept the only reason theirs is faster is because it doesn't implement the important-but-slow bits and it ignores most of the edge cases.
Even in those cases it usually turns out that the handling of edge cases was considered reason enough to sacrifice performance rather than finding a better solution to the edge case. Handling edge cases probably should not cost 10x average performance.
This seems referenced in the repo itself, see the “feature support” section [1].
That being said, is anyone aware of a significant missing feature that would impact performance?
[1]: https://github.com/cmuratori/refterm#feature-support
Screen reader support[0] may have a noticeable performance cost.
[0] https://github.com/microsoft/terminal/issues/10528#issuecomm...
1 reply →
Not necessarily, often times, especially in big corporations programmers will be incentivized to deliver things quickly, rather than to provide the optimal solution. Not because they are bad at programming, but because they have quotas and deadlines to meet. Just remember that story of how in the first Excel version a dev had hard-coded some of the cell dimension calculations as they were under pressure to close as much tasks as fast as possible.
The one example that comes to mind is file system search.
I am writing this application that displays the file system in the browser in a GUI much like Windows Explorer or OSX Finder. It performs file system search substantially faster than Windows Explorer. Windows Explorer is written in a lower level language with decades of usage and experience where my application is a one man hobby project written in JavaScript (TypeScript).
The reason why the hobby project is so substantially faster than a piece of core technology of the flagship product of Microsoft is that it does less.
First, you have to understand how recursive tree models work. You have a general idea of how to access nodes on the tree, but you have no idea what’s there until you are close enough to touch it. File system access performance is limited by both the hardware on which the file system resides and the logic on the particular file system type. Those constraints erode away some of the performance benefits of using a lower level language. What ever operations you wish to perform must be individually applied on each node because you have no idea what’s there until you are touching it.
Second, because the operations are individually applied on each node it’s important to limit what those operations actually are. My application is only searching against a string fragment, absence of the string fragment, or a regular expression match. Wildcards are not supported and other extended search syntax is not supported. If you have to parse a rule each time before applying it to a string identifier of a node those are additional operations performed at each and every node in the designated segment of the tree.
For those familiar with the DOM in the browser it also has the same problems because it’s also a tree model. This is why querySelectors are so incredibly slow compared to walking the DOM with the boring old static DOM methods.
> pretty much every time I've seen a developer complain that something is slow and then 'prove' that it can be faster by making a proof-of-concept the only reason theirs is faster is because it doesn't implement the important-but-slow bits and it ignores most of the edge cases
It's still a good place to start a discussion though. In such a case, apparently someone believes strongly that things can be made much faster, and now you can either learn from that person or explain to them what edge cases they are missing.
Maybe that's what usually happens but doesn't apply in that case.
This.
My time library is so much faster and smaller than yours. Timezones? Nah, didn't implement it.
My font rendering is so much simpler and faster than yours. Nah, only 8 bit encodings. Also no RTL. Ligatures? Come on.
The list goes on.
Don't assume. Casey Muratori produced a highly correct Unicode renderer with correct VT code support.
Watch the video: https://www.youtube.com/watch?v=99dKzubvpKE
Except that in this case it’s the other way around. This weekend project has better support for things like like ligatures, combinations of Arabic characters, RTL, etc
In case this isn't clear, RefTerm is:
1. Faster in every case tested
2. More fully-featured, including i18n
3. Easier to read and maintain (see for yourself)
4. Shorter
5. Using existing libs, aka interops well
...So none of these typical hand-wavy dismissals apply:
1. "Is it really faster for edge cases"
2. "He probably didn't implement certain features like Arabic and Chinese"
3. "Businesses just wants enough"
4. "Businesses just wants enough"
5. "It probably makes some closed-world assumption"
The performance of RefTerm didn't come from some big tradeoff; it came from using the right perspective and keeping things simple.
Sure, past a certain complexity threshold, you'd have to work for extra perf, but from my observations, folks who immediately jump to the wrong implicit conclusion that "good perf must have required compromises" got conditioned to think this way because the software they work on are already (often unnecessarily) complex.
I don't think dismissal 1 applies anyway - even if RefTerm didn't implement, say, variable-width fonts - you could just build a terminal that uses RefTerm's fast algorithms for the common case, then falls back to the Windows Terminal's slower algorithms for the more general case.
Yup, this. Something I've been ranting about[0] for a while: there is no technical progression ladder. The Senior->Principal-> ... path seems to be a faux-management track, with all the managerial responsibilities and little of the authority. Software is shitty in big part because it's mostly written by juniors, as almost anyone who has any clue moves over (or gets pushed over) to managerial or faux-managerial roles.
I've been thinking about a more charitable interpretation of this recently. Another thing I rant about[1] is that tools we use for programming are not expressive enough. It takes too much work to say simple things, the coding feedback loop is ridiculously long. So how this connects? In a way, junior programmers can be seen as a Mechanical Turk version of a Sufficiently Smart Compiler - it lets the more experienced people skip some of the tedium with the tooling and deal with higher-level concepts, which get translated to actual code by an army of juniors and interns. Except, this doesn't work that well - the coding feedback loop is even slower.
--
[0] - https://news.ycombinator.com/item?id=28568053
This definitely resonates. I've often talked about how the key transition to 'lead engineer' is when you learn how to wield a team of programmers to solve a technical problem, instead of solving it yourself, and to higher levels it's when you learn how to wield an entire organization to some technical purpose.
These ARE much clunkier tools than a compiler.
Another way I've expressed it is how the tool you use to get started on implementing a change shifts as you grow more senior (if you'll forgive an IDE-centric kind of view - this is meant to reflect life in a Big Org - feel free to substitute with appropriate emacs commands)
- Junior Dev: File > Open
- Dev: File > New
- Senior Dev: File > New Project
- Lead Dev: File > New Diagram
- Principal Dev: File > New Powerpoint Presentation
- Staff Dev: File > New Recurring Meeting Request
Love this metaphor and progression, but I thought Principal was ahead of Staff in the Ladder?
There may be a sort of sweet spot in the progression where a programmer can advance to a point where they spend most of their time figuring out the code architecture (maybe with a skeleton) for others to implement the details of, with some code reviews here and there, rather than coding as much themselves (but they still code, especially the critical pieces). This lets them still be a key player as far as programming is concerned but there's also a space for more junior programmers to learn and grow without trashing the whole project in the process. The Godot engine seems to be turning into this sort of sweet spot model with its tech lead. However in a company this seems like an unstable situation, since I've seen such leads advance another step and now the only thing they "architect" is business strategy via all-day meetings, like any other executive, and the last time they coded anything was years ago. You might get them on a rare code review but they've become so far removed from the details they're not as helpful as they used to be, which in turn leads to not including them anymore. This distance hurts again because now that they have at least some influence (not as much as the 'equivalent' managerial track position, 'mysteriously') to address long-standing dev pains they are too far removed from the pain to spend their limited influence fighting it.
My own filter for how likely a company is to fall (or be) in this trap: does the CTO code at all?
>> spend most of their time figuring out the code architecture (maybe with a skeleton) for others to implement the details of
I think a good use of the experienced programmer is to write some critical components well. I'm also with you on system level design: These are the important interfaces, you write this piece and you write that one.
Another example, I have an Oculus Quest 2 VR headset. It was fantastic when I got it in March. Now they've got some glitches where the rendering STOPs for a brief instant and the view is not updated with motion. I'm wondering if this is because John Carmack is no longer full time there and someone compromised some design principle in order to implement something. Once the glitches are in, they're going to be very hard to get back out as time goes on.
Is this not what old-school corporate dev environments did? Grunts filling in interfaces? I’m sure I’ve read this sort of thing before
There is that joke about the University Professors talking about the best high level language, throwing out various languages until one just replied with "Grad Student".
It does make a lot of sense, you describe the problem in a very high level and abstract way and at the end of the process you get an executable out of it.
But yeah, as you go up the ladder, even the technical one, you end up needing people skills more and more than any technical or programming skill. Usually by senior level you're the best that you'll ever be at technical topics (hand wavy description here, don't nitpick), and the only way to progress up is to improve communication. No amount of extra technical knowledge will help you if you cannot communicate well.
Juniors are beginners, learners, apprentices, and are bound to make mistakes and design things poorly. The issue is there are so few high-quality engineers relative to the demand, and it's hard to prove who is high-quality before they're onboard for a few months. So, if someone is high-quality, you really don't want to lose them, so you promote them, pay them more, try your best to keep them on-board. There's a benefit to elevating them out of the weeds, because often they can glance at the weeds and tell someone else how to clean it up easily, without spending their effort to actually do it.
Furthermore, they can glance at 10 patches of weeds, 10 junior engineers, and find the couple that need more guidance than the others. They can leverage their knowledge through others, assessing their strengths/weaknesses as coders in ways juniors never could.
It seems like companies are creating independent contributor tracks to remedy this issue. You can have people who are legendary programmers float around and contribute where they wish.
This is well-said and resonates with me quite a bit. How do we build expertise in an engineering organization where the best engineers are incentivized not to engineer?
I really appreciate this perspective. Better tooling to enable individuals to penetrate more layers of abstraction sound great. To some extend e.g. with cloud providers this is already happening. We have more powerful building blocks than ever. However, I feel the idea of experienced vs. junior programmer is not helping this discussion much. Experience can also hurt to some extend, because you need to unlearn things.
> To some extend e.g. with cloud providers this is already happening. We have more powerful building blocks than ever.
This is not ideal though. Cloud services have a pretty short half-life, and trap you in business relationships that you shouldn't need just to build software.
(I know, I can't stop complaining.)
> I feel the idea of experienced vs. junior programmer is not helping this discussion much. Experience can also hurt to some extend, because you need to unlearn things.
That is true, but I still think the idea is sound - there's much more universal, transferable programming-related experience juniors gain than things they'll need to unlearn later. The problem I see here is that, just as those developers gain that experience, they get pushed out to management / faux-management. In principle, this should lead to at least some improvement in quality - as increasingly better people are tutoring the next generation and directing it - but I feel we've reached a fixed point in terms of software skill, with most software being written at a pretty low level.
Quite right. Not many companies follow Fred Brooks' "surgical team" model and I would like to see more try it.
This reflects a lot of what goes on in Academia as well.
Also, if you think you can counter a "that's not possible" with a working proof of said thing working, think again, most people don't like to be shown they're wrong, particularly tenured professors. That's one of the fastest ways to sabotage your own developing career.
"Yes men" climb the ladder much easier, but then work doesn't do itself so that's the catch. Cue exploitation of interns and other newcomers and you almost have the whole picture on how things get actually done. Hence why "science advances one funeral at a time". Once someone reaches its own Peter level [1], it stops being a productive force and becomes a plug that jams everything behind it.
1: https://en.wikipedia.org/wiki/Peter_principle
Some professors are humble though.
I had a Physics 101 professor who gave a test that had a problem involving blowing a fan into a sailboat sail. The answer to the question was supposed to be that the sailboat doesn't move anywhere because of Newton's 3rd law, but one guy in the class spent close to the entire exam on that one problem showing that it would slowly move forward using a conservation-of-momentum-based approach instead of a Newton's 3rd law approach. The TAs marked it wrong and he got a low score on the test because he spent so much time on that one problem. He tried to argue about it to the professor in lecture but the professor shut him down saying to come discuss it during office hours. So he made a demo using a pinewood derby car with a hand fan glued to it and brought it to office hours and proved that it would move forward. The professor was super humble about it and brought the demo to lecture the next day and publicly gave kudos to the student for challenging the status quo.
Interesting story :-)
I wonder if they sorted out the differences between the maths approaches, so the professor could agree also math theory wise
>"Yes men" climb the ladder much easier, but then work doesn't do itself so that's the catch.
The harder the work, the lower the pay.
I would really be surprised if any tenured professor would shut down a solution to a well known hard problem just based on his ego. More likely the solution is not as well presented, researched or thought through as it seems (I'm assuming we're not talking about astrophysics here).
> I would really be surprised
I wouldn't.
It really depends on the person, but yes you have to get to know them to know how they will react. I find that this is more of a problem in the US, where tenured professors often develop these vast impenetrable egos, while in other countries, such as in the UK or Germany, they are more pragmatic. That said it is still entirely individual, and I knew who to avoid when I had certain ideas in my PhD.
Also, our German group leader asked me to take a feature from my software package because he was worried that the Americans would get upset at an early PhD student showing them up.
Actually I add something extra: I actually know an Indian professor who has become quite senior in the US, and is a more "famous" member of our collaboration, and he actually enjoys a "Guru figure" like perception when he returns to India. He says that literally people treat him like he is a lord or guru. Very strange
This is both annoying and understandable. For the dev team, to dive into this performance optimization would mean punting something else from their roadmap. I suspect they weighed their perceived chances of success against the projected cost and reached a certain conclusion which in retrospect seems wrong. The independent developer did not have that "hurdle" as he simply did this at the expense of whatever other fun programming challenges he may have done those weekends. It's awesome that he turned out to be right. But I suspect if he turned out wrong we'd never hear about it. There was likely no tradeoff analysis on his part in undertaking this project, while the dev team did have to do one.
On the flip side, I have seen developers get really hung up on what is academically difficult rather than what is practically doable. I had a young developer who worked for me get really upset and hung up on the fact that something he was asked to do was NP equivalent, meaning there's no non-exponential time algorithm to implement what I was asking for. It took me weeks to realize this was messing with him and then about 5 mins to dig into the data and show that input length never practically exceeds like 7, so an exponential algorithm was fine. So I can see how a dev could get stuck thinking something is really hard when it really isn't. But I don't think it makes them a bad dev, it's just hard to transcend your own perspective.
I remember clearly when I first gained a real appreciation for the importance of measuring and considering your actual data.
I was trying to optimize a slow project doing some polyhedron dissection on large (~1M polyhedrons) meshes in real-time. As a first attempt I had my sights set on a function which tried to find a certain point on a surface by making an educated guess and then iteratively bumping its estimate in the right direction. I figured "I can solve this analytically instead!".
I did, and it made things approximately twice as slow. After scratching my head and outputting some data I realized my constant time solution required a number of expensive operations including sqrt and the iterative approach ran on average ~1 iteration and at most 3 iterations for just a handful of these millions of triangles.
> I realized my constant time solution required a number of expensive operations including sqrt and the iterative approach ran on average ~1 iteration
Yeah! It's deeply unsatisfying to forego algorithmic optimization but it often isn't necessary.
EG, when I do Advent of Code, I often write a naive algorithm that works correctly on the sample input, and then runs a really long time on the actual problem input. Before I go redo the algorithm, I often run it with PyPy instead of the standard Python, and 80% of the time it terminates quickly enough.
Similarly, whenever I happen to do AoC in C++, my naive algorithms happen to magically be fast enough out of the box so I don't even think about better algorithms. It's unfortunately counter to the intuition that you get from a CS programs that obsess with Big-O notation rather than implementation speed.
Big-O is really important but it seems like the input size where it starts to dominate implementation is much larger than our intuition suggests.
(of course it's also easy to write really bad algos that suck even on small input)
1 reply →
Reminds me of the time I spent ten days building a memory allocator based on a red-black tree to optimize lookup times for an interpreter that needed to be fast. When I compared its performance against a linear search, it failed miserably. Turns out the fixed overhead in implementing a red-black tree vastly outweighs a naive approach when you're only dealing with 20 terms or so.
I'm not sure "It doesn't take a PhD, just years of experience" is quite the rejoinder the author thinks it is.
Aren't they both just ways of saying "It takes someone with a rare subset of highly specific knowledge to solve this problem"?
The MS person was saying "Sure, there's probably a way to make this faster but I don't have anyone on my team who knows how to do that. If I had the budget to go out and hire someone with a PhD maybe I could do it."
That then Casey Muratori could show up and do it in his spare time doesn't really refute that argument, does it? This is someeone who has spent years actually doing hardocre R&D work, and literally published techniques that advance the state of human knowledge in the field of GUI rendering[0]. His resume is kind of a living example of 'PhD, or equivalent professional experience'.
So sure, it might be nice if MS's career structure led to them having more Muratoris on staff, but I don't think the expectation that every product team should have one or two developers of that caliber on it is a reasonable one.
It IS a good argument for why MS should accept open source contributions, though.
[0] https://caseymuratori.com/blog_0001
It's not really what the MS devs said though: "I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation"
This seems to mean, nobody has ever done that, it is a research project (a doctorate thesis must be about something that has never been researched before, at least where I live).
This particular problem cannot be a PhD subject, because it has already been researched, solved and done multiple times, by different persons and on different projects.
Someone can use the knowledge already widely available on the internet to grasp what the issue is, and implement a solution in their own project.
Years of experience aren't a PhD. Years of experience can help you understand a thesis, but only if the research doesn't exist yet, can it be considered a doctoral research project.
So the comment that the 'PhD' reference was responding to was Muratori laying out how he figured a simple terminal renderer could be implemented, using two texture lookups in a single drawcall [0].
In the course of that, Muratori allowed, almost in passing, that of course you would need, in order to do that:
> a glyph atlas encoding the cell-glyph coverage in whatever way makes it easiest to compute your ClearType blending values
Now, it does not strike me as beyond the realm of possibility that that step might be suitable for academic research. It calls for an efficient encoding of cleartype-ready glyph data with comprehensive coverage of unicode glyph space (not codepoint space). That's not trivial, and - as the DHowett reply suggests - it would take a literature review to determine if someone has already accomplished this (and he also suggested that so far as he was aware this was not how any other terminal was implemented, implying this is not simply some well known solved problem).
I mean, sure, he could be wrong about that - it might be exactly how another terminal implements it; there might already be published research on the topic; or it might just be much simpler than it appears. But it's not crazy to, on glancing at that problem, consider that it seems like it might actually require genuine original high level research.
[0]: https://github.com/microsoft/terminal/issues/10362#issuecomm...
2 replies →
I think the other piece the comment and the rejoinder miss is is: A PhD generally means you've done four years of work post bachelors, and some of that work was novel.
A PhD alone does not make someone an expert in most modern senses in software. The folks the author describes as "experienced" often have more than a decade of working software knowledge from after their education.
Casey Muratori has 30 years of programming experience. That's not a PhD, that's a PhD and then an additional 20+ years of experience.
And to be clear, Microsoft probably has plenty of people capable of writing this kind of code. They just aren’t working on console.
In fact, consider the hypothetical of: what if Microsoft had hired Casey Muratori.
Do you imagine they’d have put him on the console team?
I mean the Windows console, not the X Box console, or the Minecraft console.
Microsoft has _Micheal Abrash_.
He wrote The Book on rendering performance. Michael's super optimized x86 assembly routines for lighting and texturing is the reason we can run Quake on toasters.
Anyway, I don't think they should hire Casey. Specially after that demonstration of not understanding the big-picture and not being a team player...
4 replies →
Would just like to say that:
1. WT is probably my favorite Microsoft product
2. Since this whole affair, the developers have apologized and corrected themselves which is usually unacknowledged in these discussions.
3. The developers have made a number of performance improvements since (most of which are in the latest preview release).
4. This episode is constantly retold and used to bully the developers even after these apologies and this has lead to one of the developers to quit (paradoxically one of the devs who after these posts made the most effort to figure out where the bottlenecks are).
If that's the case, they should really link those developments/retractions/apologies in the comments of that issue. The way the comments end in that issue is a really bad look, and there's no hint to the reader that there was any further developments, either in the code or the dev team.
Maybe, yeah. I don't have everything ready at hand but maybe take a look at:
https://github.com/microsoft/terminal/releases/tag/v1.11.242... (Latest release, check the PRs linked under performance)
https://github.com/microsoft/terminal/issues/10461 (Issue discussing rendering from a glyph atlas)
https://github.com/microsoft/terminal/issues/10462 (This is where one of the contributors quit)
https://github.com/microsoft/terminal/issues/10623 (Bullying example)
It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way.
Leadership is a lot more than about "shuffling paper" in an "ivory tower".
As a lead (in any decent company), you get to participate in critical design reviews; you get to read and review code; you get to shape the trajectory of others; you get to participate in discussions with the product teams. If you work smart, you get free time that you can use to keep coding. All of this can be extremely rewarding.
You are not serving our domain by painting this kind of picture of leadership. The truth is, you can excel as a software engineer, but you can also excel as a lead. And none is better than the other.
I dedicate this message to the "wet behind the ears" people you are referring to who would never consider the role if they were to stick to this poor vision you're delivering.
> And none is better than the other.
I agree with you, but few companies know how to appreciate those who decided to progress in the technical excellence. In most not taking a "leadership" (aka management) position means your career reaches a dead end.
> It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way.
I think you misread the post.
I don't see where this is criticizing the role of leadership. Good leaders exists (though, they are rare). I have been led by some of those inspiring people. But I've never met a leader (as good as it was) who continued to be a great software engineer.
The point is that they all were stuck in the "Sort of knows what they are doing" zone. And that's ok for being a great leader. But then, nobody in the company is kept long enough at a position to become what the author describe as "Experienced".h
> It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way.
It saddens me to time and again be stuck with "leaders" who don't know what they are talking about and think they need to weigh in on everything, even though they add negative value when they do so, because they want to justify their mostly pointless job.
In a 14 year career, I have had "leadership" that is not completely horrible for about 6 months, but that I still would not call good, at best it is mediocre. If only most "leaders" were wet behind the ears instead of bordering on grossly incompetent.
If people's experience of leadership is that it is almost always dead-weight, then the problem is that it is almost always dead-weight, not that people call it out for being almost always dead-weight.
And by the way, I have never met one person who thought they were a good leader that was even slightly so. People who think they are good leaders are almost invariably pompous, arrogant and ignorant.
So have you met any good leaders? Or are you saying that good leaders are nearly impossible to find (and therefore perhaps the job is difficult?)
3 replies →
Of course we have all met people who were pompous, arrogant and ignorant.
But there are some good and outstanding leaders out there. If you never had the chance to meet one (or did not recognize them when they were in front of you), I am sorry for you.
2 replies →
If you read the article, the author is discussing a conversation on Github and developer experience. The article isn't an indictment about academia (it doesn't even really come up at all).
Re the author's competence argument, given how complex software development is as a field, a better approach should be to always assume that there's a person out there who can solve a problem quicker and more competently than your guesstimate. Of course, you should also assume that they're not going to, and that you - with all of your issues, lack of experience, and general :/ 'iness - is the one who's either going to have to fix it or find someone who can.
The worst part is that the kind of arguments he was met with is exactly the kind of arguments people use to get headcount and climb the ladder within corporations.
Spending a little time writing a well designed and fully working solution => Good job, now take the next ticket!
Spending a lot of time explaining why something can't be done with this budget => Promoted to manager!
Spending a year of time explaining why the project need a much bigger budget to deliver features => Promoted to director!
This is the main problem.
This is neither the problem nor what the article is talking about. Your argument is so overgeneralized that i don't even know where to start taking it apart.
Cultural issues are almost always tied to performance evaluations at a company, so it is highly relevant.
If this wasn't the problem then their manager would have reprimanded them for posting such nonsense. But either these objections were made by the manager or the manager agrees with them. Why would a manager who is fine with such bullshit still have his job? Because it goes all the way up the chain, otherwise someone would have cut it off a long time ago.
I understand that different people have different skill sets, that's totally fine. I don't think every single senior developer at Microsoft should have the skillset to fix performance issues like this. That said, however, I do think developers should be able to recognize when a task requires a skill that they do not have. In those cases it's best to reach out to someone within the organization who has that skill. Or, you know, you can be a senior developer at Microsoft and condescendingly claim that it's impossible, or "takes a PhD to develop that". I guess this is what you get when you fill organizations with people who don't care about performance, computer science or algorithms.
I'm going to use this case as another example to point to when people argue that algorithm skills are useless and shouldn't be used when interviewing.
I don't think this is about algorithms.
Yes it is. When you have 2 programs that do the same thing, except one program is orders of magnitude faster than the other, it's almost* always because the faster program is written with better algorithmic time complexity.
(*In some cases the big-O time complexity may be the same for 2 programs, but one program can still be much faster in practice due to micro-optimizations, heuristics, etc. Even in cases like this, people who are good at algorithms will be better at writing these heuristics and micro-optimizations than people who don't care about algorithms.)
7 replies →
I feel this is missing the elephant in the room, which is that experts are not interchangeable. They have typically specialized in whatever they have spent lots on time doing, and so developers in different sectors develop a lot of different skills that are typically not very useful for developers in different sectors.
A result from that is that what may be trivial for people in one sector is hard for people in a different sector, and vice versa. Often people will not know enough about sectors different from the one they operate in to know what is hard or not in other sectors.
Counter argument: If the experienced programmers stay where they are, software development will forever remain craftsmanship. A single developer can only tutor so many juniors.
In fact, I think that teaching and encouraging to learn is the most important thing in SE. And that has to begin with leadership figures that don't believe their own knowledge gets obsolete after one year just because the latest framework got released.
SE should not be an art form. It should be founded in solid science and abstraction should allow us to keep our knowledge applicable. You're not a bad engineer because you never touched the latest hypetech or programming language. You are a bad engineer if you only consider yourself a "frontend developer with react on chrome".
All IMO, of course.
> SE should not be an art form. It should be founded in solid science and abstraction should allow us to keep our knowledge applicable.
Software engineering can never be anything but an art form!
A lot of fields of endeavor have both mechanical "science-based" components and creative "art form" ones. An inexperienced chef can get some productive cooking done by mechanically following the steps of a recipe someone else wrote--cutting up vegetables, operating the stove, and so on--without making culinary decisions of their own. Experienced chefs, though, come up with ideas for things to cook, which you can't effectively do just by following some procedure. You need to have some creative je-ne-sais-quoi.
In software engineering, we have no long-term need for the first category of people. Any programming task that doesn't require human creativity can be automated. (When's the last time you decided which CPU registers corresponded to which variable names in your program?) An effective programmer uses abstraction for precisely this purpose. They spend all day, every day on making the hard decisions, and they let the computer handle the rest.
This is why Enterprise Software Architecture techniques have always been and will always be doomed to fail. You can't have senior engineers come up with rules that junior engineers can just mechanically follow to write good code. If you could, you wouldn't need the junior engineers, since you could just tell a compiler or code generator or something to follow the rules instead. Everyone who works on a codebase needs to be capable of making good decisions about code, in a way you can't boil down to science and checklists, or the best they can ever do is waste their own time producing repetitive boilerplate.
If you look closer everybody who create something on work, like every craftsman, is a kind of an artist. But it pays very badly, so even for people who like the job, are forced to step up into the office, because of the better pay. That is part if the reason, why you almost can't find a good plumber or electrician. If you can count to 2, you are forced out of the job. As you long, as you write software by yourself, you are not much different than a plumber .. you work with your hands.
2 replies →
I get this sentiment often, but I think it is incorrect. Software developers should not consider themselves artists - they should consider themselves designers. Yes, a designer has some freedom to express themselves, but mostly they should satisfy the customer. Think of someone designing a lamp for IKEA. The functional and nonfunctional constraints outweigh the artistic freedom by far. Software developers have one advantage over the poor soul that has to come up with that lamp, though: For us there is serious, hard, science that tells us what can and what cannot work. The IKEA designer must rely on market research.
I think you've got heuristics and art form mixed up
Good software development can't be anything but craftsmanship, or art if you think of "art" as in "artisan".
Think of what a developer is, and what a computer is. A computer is a dumb machine, it lacks creativity, it is only good at executing orders, but that, it does it very well, and very fast. A programmer is a human, creative and able to see the big picture, his task is to inject his human qualities into the dumb machine, so that the machine can do things that are useful for humans.
So, programming is the opposite of applying recipes, if there is a well defined recipe, that's for the machine, not for the human. If programming is not an at least a little bit of an art form, it means the programmer is doing the job of the computer, which is a waste of valuable human time on something the machine can do better.
I'm somewhere in the middle. I see software development as an art form, however it's not disconnected from its solid scientific roots.
Sometimes, the art part is for fun (i.e.: your weekend project), sometimes it's for pushing systems to the limit (i.e.: scientific programming, demoscene, or where performance is really needed).
In my case, the art is exploiting the hardware or the theory in a way that it works smoothly and very performant for the cases you have.
This doesn't mean the deadlines doesn't matter, and explicit, slow, but very robust code doesn't have its place. On the contrary, it has many places. We need to make the correct trade-offs to get our job done the best way possible.
On the mentoring side, training people is hard, because of both parties. Low ego, open mindedness and being open to being wrong is very important. I try to mentor some people around me, and I encourage them to go further than I did. Lastly, I find passing the "old way" to new generations very valuable. While these old ways are inevitably lower level and less hip, they're tried, stood the test of the time, and generally performant enough (or very performant in some cases).
Just a side note, your idea of art is a bit naive. Take for example the work done by Christo and Jeanne-Claude, citing wikipedia:
> Their work was typically large, visually impressive, and controversial, often taking years and sometimes decades of careful preparation – including technical solutions, political negotiation, permitting and environmental approval, hearings and public persuasion.
I pity the developer (or maybe manager) at Microsoft who wrote the GitHub comment on which this article's title is based. (And no, I never met him when I was at Microsoft.) If he's in the Seattle area, he's likely not even awake yet, but when he is, I expect he's going to have a bad day. Assuming he's not already sick of the Windows Terminal versus refterm drama, it would be interesting to read his perspective.
As the guy responsible for that comment (and the dev lead for the team! Hi!) I can say it haunts me pretty much weekly. My parenthetical-laden snarky sense of humor, my use of italics to indicate speech-like emphasis and pretty much everything else about that comment has been dissected to parts as small as possible.
In the end, though? Yeah, I was completely wrong. I don’t know much about graphics engineering and I’m glad(^) that we were shown up by somebody who does.
I’ve been working in software for nearly 20 years, and I’m firmly in the “knows enough to be dangerous; doesn’t know everything” category the article is missing. It’s not, as some have characterized in this comment section, because I moved into leadership; rather, it is because there is not a single axis on which to measure all engineers. I’m inexperienced in graphics and text layout, and my critical mistake was not respecting the experience somebody else brought to the table. In other fields, perhaps I fall higher on the experienced/wet-behind-the-ears scale.
(^) I may flatly disagree with his presentation and his group of fans taking every opportunity to slander us, but I’m happy that it’s generally possible for us to improve performance and engineering efficiency using the technique he described. :)
> his group of fans taking every opportunity to slander us
Conversely, I think I went overboard defending you and your team, to the point of making my own over-broad generalization about game devs in another subthread [1]. I'm glad it's practical to get the best of both worlds in this case.
[1]: https://news.ycombinator.com/item?id=28744315
1 reply →
My sympathies to you and the rest of the WT team. I think you’re doing a bang-up job under difficult platform constraints (that most people don’t appreciate), and the amount of vitriol spilled over this one interaction has been really disappointing.
Just remember that there’s a huge number of people who appreciate the work you’re doing to modernize terminal experiences on Windows (nearly 78k GitHub stars!)
yeah, i would be really sad if I was at the receiving end of this.
One guy is not 100% correct one day (because we overworked devs always are?), and the next day someone has written a blog text painting him as a subpar dev and now he is on front page of HN used as an example...
Yea, it's been a generally shit experience. Knowing the sense of humor of the original "PhD" comment, yea, I read that as a light-hearted jest, which was definitely lost in transit. Communicating on the internet is hard. Miscommunications are easy, and this one happened to spiral quickly. It saddens me that this whole incident was used to balkanize the community rather than to work constructively together.
Holy shit you sound annoying and wrong about Everything in this thread
The very ticket [1] is locked by this epic ending:
> You were overly confident in your opinion, but I hope this website helps you understand that it's actually really damn hard.
> The reason your program shows a high FPS under other terminal emulators is simply, because their rendering pipeline works independent of VT ingestion. Gnome Terminal is not laying out text faster than your display refresh rate either. And of course, again, this is something WT will probably do as well in the future... but this project is nowhere near as old as Gnome Terminal is.
[1] https://github.com/microsoft/terminal/issues/10362#issuecomm...
The github issue is a gem.
The reporter is basically being fobbed off by being flooded by random buzzwords and data points, none of them specific, but he keeps trying to drill down to specifics by asking questions.
The tone gets quite condescending towards him.
He gets out of all this with flying colours. He should consider adding that Github issue to his resume.
He is already well-known enough in his field past the point of writing a resume, and I don't think he really would want to enter the corporate IT world that he intensely despises (even with lots of cash). Plus he's already busy on his own working on various projects: the video game 1935 (which we don't really know that much of), Star Code Galaxy (a CS course focusing on fundamentals), and Handmade Hero (A live recording / tutorial of making a game from scratch). He's already really
Damn, my brain died while writing that one.
Yeah, typical Microsoft developers (https://github.com/microsoft/terminal/issues/10362). That issue was pretty mild, they felt threatened and used CoC principles ("combative") to shut down the threat.
This is how they also ruin "open" source projects like Python now.
That's a pretty terrible interpretation of events here. Along side the "combative" phrasing was a bit of self reflection
> Setting the technical merits of your suggestion aside though: peppering your comments with clauses like “it’s that simple” or “extremely simple” and, somewhat unexpectedly “am I missing something?” can be read as impugning the reader. Some folks may be a little put off by your style here. I certainly am, but I am still trying to process exactly why that is.
That post is literally not trying to shut down the conversation, it's simply reflecting on the tone of the commentator. elsewhere in the comment he even prompts for more discussion on the topic. At no point is the CoC invoked.
> I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively…
Yes, it might be seen as combative since it amounts to saying "you guys seem to be clueless". When proven in experiments, it means that the combativeness was justified.
Imo, the language in this quote is almost unacceptable. It's a roundabout way of saying "stand back little peon, you are not important enough to be thinking about problems that concern us."
It's inevitable that when people overestimate their competence and judgement, the moment when humility is forced on them is experienced as painful. Adjust prejudices and move on.
Saying that is is a multiyear long undertaking was probably a little silly and makes it sound like the person who said that can't have been involved wi4th the software otherwise they would have known this but there might also be another explanation that we have seen, particularly with Microsoft:
You can't sell the things that make people just like the software, only new headline features do that.
Example 1: When you open visual studio 2019, you get a search box by default that allows you to type in your project name and it looks for it in the MRU list. Except this is intolerably slow! I suspect it might not be the searching itself, perhaps a tonne of threads are doing something but it is terrible. ANY search algorithm looking through a list of no more than 50 things should be instance, theirs takes up to around 10 seconds and does fuzzy search by default! Why don't they fix it? They wouldn't sell any more units by fixing it and you won't upgrade to the newer improved version.
Example 2: When you install nuget packages in visual studio on netfx projects, it modifies the assembly redirects in web.config by re-writing the entire file even if there are no changes. Oh, and it adds extra spaces and stuff so that the diff tools think every single line has changed. I have to manually delete all of the entries, build it again, let visual studio warn me about missing redirects, double-click the warning and VS writes the file in the original style revealing the maybe 2 actual changes. This is total horsesh*t but they won't fix it. Why? You should be using dotnet core, even if your project is 5 years old and established.
It's a shame because there are lots of things to like about MS tooling compared to lots of competitors but each of these things will be a coffin nail that eventually will cause people to jump ship.
The difference here is that the developer of RefTerm is an experienced, professional developer passionate about his craft and building good software. Microsoft is a faceless entity composed of people who mostly don't care about what they do during the day and are just getting by so they can get paid. There's no shame in that. But there is shame in patronising someone when they demonstrate something to be false and locking the thread on GitHub such that no further discussion is possible...
Microsoft is sluggish and delivers products that do the job and nothing more. Sadly, that's the modus operandi of most software companies. That's why nimble little startups are still managing to steal pieces of various markets.
I use Windows Terminal quite often and have definitely noticed its terrible performance. So this is definitely something visible in the real world and not just nitpicking.
> Microsoft is a faceless entity composed of people who mostly don't care about what they do during the day and are just getting by so they can get paid.
Regardless of what you think about Microsoft the company, please remember that the individual workers and managers are people who can be hurt by our tendency to form self-righteous mobs. And according to another commenter [1], one of the people working on Windows Terminal was hurt to the point that they quit.
Full disclosure: I'm inclined to defend the Microsoft team here because I was at Microsoft (on the Windows accessibility team) for a while. I don't think that I or my former teammates fit the stereotype you described. And while I never met any of the developers on the Windows Terminal team (at least not knowingly), I could very easily have crossed paths with one of them; I believe my team used to be in the same building as theirs. So I'm inclined to be charitable.
[1]: https://news.ycombinator.com/item?id=28746624
This might get me some shit but running away like that isn't a good trait to have. Not for Microsoft, but also not for themselves. This will probably be in the back of their mind for a chunk of their career since they have no closure.
I would expect somebody working on a greenfield project at one of the biggest software companies in the world to tackle issues head on with grace.
Those individual workers hurt the project and the community around it by setting the precedent that you need to create your own competing product to verify that bugs can be fixed without PhD research.
Nobody should be harassed over their open source project, but that doesn't mean actions don't trigger reactions.
1 reply →
inexperienced developers are unable - or just rarely - ask themselves the question:
"is the current performance in the right ballpark of where it should be?"
here it's obvious - muratori took one look at that thing and just knew that "no, 2-3 fps is definitely, completely off". i, too, had a couple of those moments where i got my hands on some code and thought: "that just can't be right" and then found O² algorithms, byte-by-byte io copy routines, database abuse or duplicated work.
if you don't have the rough reference points of what should be right, you often just don't question correctly working code.
In my experience, basic coding skills can really atrophy in senior developers who quit writing code years ago and are full-time architects/managers.
I’ve interviewed more than a handful of extremely accomplished people with decades of experience as developers and then engineering managers who couldn’t answer extremely basic coding questions (we’re talking “efficiently find duplicates in a list” or “compute Fibonacci numbers” basic). These people never could get past the O(n^2) brute force solution for finding duplicates (or the brute force compute every Fibonacci number starting from 1, 1), because they hadn’t thought about even basic algorithmic complexity in so long. And when people like this are giving orders from the top, you can see how software can get so slow.
I have no doubt that when these people were actually still coding, they could have answered my questions in their sleep. Quitting coding for engineering management really does one a disservice IMO. To this article’s point, I’ve also had the pleasure of working with people with decades of experience who never quit coding even as senior managers and their level of competence and productivity is astounding.
This is why I am considering leaving my current position. "oh we have something you can work on, but first can you..." 3 straight years of this...
I really cannot fathom how one could forget fundamentals.
I can prove the average complexity of quicksort with simple math transformations of initial recurrence equation which I do not even have remembered but I'm sure I could derive. Last time I did this was maybe 8 years ago if not more.
Yet somehow an accomplished dev cannot spot accidentally quadratic behavior when coding in something that is not Haskell.
IMO, the average dev and average accomplished dev is no longer the kind that knows the fundamentals. Not that it's necessary in all cases but eventually everything will look an equivalent of a doctoral thesis when the average codes the spaghetti mess.
Recently I was reviewing code with map(find).sort(indexOf) (O(n^2 log n + n^2) behavior) when it could have been a simple dict; map(dict.get) (O(n)). This person has 10 years of coding experience. When looking at the resume, the dev is pretty accomplished, productive, and worthy of the salary. But I assume the knowledge of fundamentals was missing from the start.
Reminds me of the Expert Beginner: How Developers Stop Learning: Rise of the Expert Beginner https://daedtech.com/how-developers-stop-learning-rise-of-th...
PhDs often make the worst possible developers. People with PhDs (especially in Mathematics) are often lacking the most critical characteristic of a good developer; they don't know why they do things. Being good at math requires being able to solve problems whose solutions often do not have any practical uses or whose practical uses may not be clear. This is very different from how software problems should be approached. Software development is more about finding the right problems than it is about solving problems; to find the right problems, you need to understand the 'why' in as much detail as possible. Every line of code should be easily justified by how it brings the system closer to achieve its purpose. The PhD diploma itself doesn't have much practical use in financial terms; it's not a good investment to get a PhD for purely practical reasons. Detatchment from practicality is the worst attribute someone can have as a developer.
> PhDs often make the worst possible developers.
I personally don't agree.
> Software development is more about finding the right problems than it is about solving problems; to find the right problems, you need to understand the 'why' in as much detail as possible.
This is what a software or CS PhD makes you understand. You know the why's to the lowest level possible.
> The PhD diploma itself doesn't have much practical use in financial terms; it's not a good investment to get a PhD for purely practical reasons. Detatchment from practicality is the worst attribute someone can have as a developer.
In my experience it's the opposite. After I got mine, I realized that I can answer these "Why"s faster, infer my own knowledge and can write better code easier and in less time. The whole process got much entertaining too.
So, YMMV.
I say, it doesnt matter, PhD or no PhD. Alot of the smartest people in the world have no PhD.
What i will say is that, i suspect PhD people to be people that create more theories around how to solve certain problems. And this. is very very very bad. It leads to design patters and generic solutions aka. lazy solutions that are just bloated and slow.
And this is a problem i see often with people who learned to code via school/university or some code academy like BS.
Design patterns are evil, and solutions should always be custom made towards the problem and be made as simple as possible. Only then you wont end up like microsoft or 95% of all developers.
> Being good at math requires being able to solve problems whose solutions often do not have any practical uses or whose practical uses may not be clear to you. This is very different from how software problems should be approached.
I don't really agree. Being good at mathematical research requires recognizing the "core organization structure of a system" and solving the "core problem at hand". I'd argue that it's essentially the same in programming (and business) as well. The main difference is that a mathematical researcher is able to ignore non-pertinent information, while in practice those issues (usually) need to be dealt with.
That said I wouldn't say that PhDs (math or otherwise) make great developers. Their skill in development is a result of experience in developing software within the software industry and not something they gain simply due to "being intelligent" or by working on their on on their POC research implementations. But I'd point out that it's basically the same for professional software developers as well.
However, there are probably infinite organization structures describing a complex system and there isn't any ontological reality to Occam's razor. Programming is really much about deciding where and at what level to allocate partial structure, which again informs the broader picture of the core organization – and some of this may be even intuitive.
1 reply →
A bit if a generalisation. For a different view: currently almost all the core devs for NumPy and SciPy (those are the ones I know personally) have doctorates.
I think that we can agree that if you want to become a generalist programmer, able to hop from random web startup to random web startup, then a PhD is probably not that useful. If however you want to become more of specialist, say being able to develop novel solutions to complex fluid dynamics problems then a PhD is very useful place to start.
Meh, it's better to treat software development and underlying academic competencies, like mathematics, as completely separate fields.
Sure, the latter helps the former, but rear in seat experience is best for (I'm assuming) both.
I have a PhD (physics), and I worked in a quant team with maths, physics, engineering and comp sci PhDs, and I can assure you the bell curve demographic is identical there as it is in a department of non PhDs. There are some very good developers, the odd mythical "10x" developer (in this case, someone that really just writes repeatedly same thing in every job to be honest), and some very poor developers.
> The PhD diploma itself doesn't have much practical use in financial terms; it's not a good investment to get a PhD for purely practical reasons.
I don't know if you say this because you have don't have one, or haven't worked with many (not just one) PhDs?
In the UK at least, your starting salary will be significantly higher than just a plain degree, and it also opens up a broader job market (in the City, at least, and aerospace and defense) where PhDs can be a requirement in some jobs because (junk) degrees are now ten-a-penny.
You learn writing skills, and analytical skills both of which are financially useful and practical.
I get the feel that what you're implying is that PhDs are less imaginative and perhaps less likely to be entrepreneurial. In that case, you may have a point.
My point is that, on average, in my experience, they are more interested in big complex theories and hypotheticals than in reality and all its tedious subtleties. They can miss the point that all these tedious subtleties add up in terms of complexity and shouldn't be scoffed at.
This infatuation with complexity is itself a big problem. I've observed a lot of PhDs neglect the cost of complexity. Choosing complex solutions with significant practical drawbacks over simpler ones in order to get some tiny gains in performance (for example) or to get some specific characteristics which they feel is important but which the average user doesn't care about at all.
I find this generalization a bit hard to believe. Good academic researchers should be obsessed with knowing why they do things. After all, researching the state of the art and identifying a knowledge gap is what they do. And they should also be quite good at documenting the how since they write a lot of methods sections.
Maybe not in mathematics as I have no idea what a math PhD thesis looks like but for all other fields I know I'd expect a good researcher to be exceptionally good at giving a reasoning for why they do something and also at knowing what other approaches were tried by other people and what the pros and cons are.
But I find the comparison PhD vs. developer a bit unfair. I agree that you become a better developer if you develop for 4 years instead of doing a PhD. Even in CS, a PhD entails many things that are not developing, namely writing papers, getting grant money, teaching etc.
However, I also agree with you that if the goal is to become a better programmer, a PhD is not the way to get there (imo).
If you're hiring a PhD Mathematician and expecting them to be great developers, then you're quite frankly doing it wrong. Don't get me wrong there are great developers with a PhD in mathematics, but that's got nothing to with their PhD (in general). You hire a PhD mathematician because you have math problems relative to their expertise that you need solving, and if they're not great programmers you pair them with a great programmer to help implement their solutions.
According to the Amdahl's law: Let the smartest do the hardest. According to the Gustafson's law: Add more work if you want to keep the others busy.
cmuratori is great software engineer, for sure, but, god, this bug report poisons the well right from the start (see below).
Also the report is actually quite bad, because 40x performance drop, that is stated, could be actually nothing. If something takes 1 millisecond instead of 25 microseconds (numbers from the head, to illustrate the point), it might be an issue, but also might mean nothing. This is the thing that requires clarification, from my pov.
Regarding poisoning the well: instead of writing
" Expected Behavior
Despite the increased parsing load, modern CPUs should not have a problem parsing per-character color escape codes quickly. I would expect the performance of the terminal to be able to sustain roughly the same frame rate with per-character color codes as without, and if there was a performance drop, I wouldn't expect it to be anything close to 40x. "
he could just write
Expected behavior
Frame rate of output with per-char color codes is similar to non-colored output.
> 40x performance drop that is stated could be actually nothing.
It isn't though. The performance difference between Windows Terminal and refterm is dramatic enough that he could demonstrate it in a video.
And that is why I'm saying that initial bug report could be done better.
For example, out of curiosity I did the test from the last message: doing "cat big.txt" in WSL2. In Windows terminal it took 1.5s, but in Kitty terminal, that is running under wslg (same ubuntu version), it takes 0.34s. Powershell, from the other side, is awful (20-25s).
1 reply →
I personally disagree. I don't see any poisoning in the original bug report; furthermore, I think it conveys the issue (and some of its subtleties, such as referencing "modern CPUs") much more clearly than the version you propose.
Agree, pretty unfriendly tone. I would expect from a more senior developer that he or she has a high enough social intelligence to understand how to confront others with their findings in a clear but friendly way.
> Expected Behavior
Whether this is interpreted as unfriendly depends on the stance of the reader. I can easily make this sound somewhere between "celebratory" or "intriguing" when I read it. If I were the author and performance/bug-reports somehow meant negative consequences for me, then it would sound hostile.
i find the expected behavior paragraph perfectly fine.
> Due to the way the programmer’s ranking system works, an average company will have a big crowd of inexperienced people and very few who can tackle complex problems. For this reason, the vast majority of software is written by the ones who are still learning the ropes.
I wonder if another reason is just that it’s such a growing industry. The number of CS grads each year are growing, and I know tons of people who sidestepped into the profession from other degrees as well. The number of jobs too. If the job market is twice the size it was a decade ago, half the employees are going to be new no matter what. Perhaps hilariously, that huge demand means high wages, means more early retirements, means fewer senior people too.
> it seems to me that the software industry doesn’t value technical excellence as much as it values having warm bodies report to you
Naturally. Computers don't pay, these wet bodies pay progressively for values they perceive. Technology is merely an instrument to add amounts of currency value to products that it is to hold. Also, a business that relies on technical excellence of small groups of individuals is not a business well conceived.
Logical complexity impregnated into an artifact, logical or physical, is a completely separate phenomenon to currency values it holds within the system of human economy. Took me way too long to get it. The fact that the two are considered same is itself probably something worth discussions.
I tihnk I generally agree with this, but also wonder what the alternative is.
If you step outside your own industry, do you want plumbers that have a hobbiest appreciation of the intricacies of fluid dynamics, or do you want someone to come and unblock your toilet in the middle of the night?
There's possibly a middle ground where the geniuses invent toilet technology in such a way that it is easy to install and maintain, and "normal" people do all the other boring bits, like stocking warehouses, transporting it, selling the house it sits in, answering the phone etc. It feels like we've generally got there in both plumbing and in software and is that a bad thing overall?
I just want Microsoft to develop a proper terminal application and not handwave away complaints about performance with "that's a PhD right there". Even if it was a PhD, I'd then expect a PhD to be put to the task, because this is a crucial component of the operating system.
Realistically though, a PhD is the opposite of what you want here. A PhD is almost by definition an inexperienced programmer. It's also someone who is likely to fall in love with their ideas, putting aesthetics or purity above practicality and effectiveness.
I was more responding to the article, which used that specific example as a jumping off point to talk about management structure in software development generally.
I don't use Windows, but I do use Kitty terminal (https://sw.kovidgoyal.net/kitty/) and from my interactions with that project and trying to get code ligatures working in my setup I've learned that terminals are really complex, both for technical and legacy/ecosystem reasons so my gut reaction is to support the MS engineers, without having read deeply into that specific issue.
edit: having read some more of the original ticket, I'm more firmly on the MS developers side. I think the other person is both rude and uninformed about what they are talking about, which is a terrible combination.
4 replies →
This would be a nice thesis. Unfortunately we have software like memcached, redis, nginx, Envoy, Kafka, Zookeeper, and more that come straight from professional programmers which makes this thesis more complicated than this post makes it sound. Perhaps Occam's Razor should apply here.
That software from a pool of millions of SWE across the world. And importantly this software created outside of corporate structures! I think these exceptions prove the rule.
Most SWE are working for companies that don’t make money reinventing architecture. Leading a bunch of people to use existing tools to sell something to customers is probably where most of the value comes from in SME world and probably most of the big company world too.
Everywhere I have worked the very experienced people are probably doing the “the same year repeated many times” rather than a pyramid of experience taking on more complex engineering challenges.
There is a lot of money in glue code.
"Everywhere I have worked the very experienced people are probably doing the “the same year repeated many times”
Yeah...
Maybe it takes PhD to develop that through the Microsoft development process.
At one of my previous companies they hired two engineers specifically for performance. They were sharp guys. Problem was, they were put on their own team/silo and basically no one involved them in any of the work. Their PRs were considered more of an unpleasant intrusion into other peoples sprints. They became useless because of the terrible organization! Total wasted talent because "performance" was an afterthought in every respect.
Nope!
It's just that in corporate world, developers rarely do what they think is relevant for them.
The people who did Windows terminal probably cared a lot about COM or WinAPI or maybe CS, but I think it's fair to imagine how they were not fans of text-oriented interfaces. It just did not occur that they should be extracting last bit of performance here. People can type just that fast, after all.
TBF we've actually maintained the Windows Console for the better part of 5 years and we're incredibly passionate about performance. We live and breath in the commandline. Performance has always been one of our P1 priorities, because improvements to the console have second-order impacts on the entire commandline ecosystem.
There is an engineering tradeoff though - we've only got so many devs and at a certain point you have to say "good enough for now, we'll come back to this, let's go do this other thing for now". The Terminal is faster than conhost was, and that's a good place to start, but I don't think anyone things we're done working on the Terminal, and we're certainly not done working on its perf ;)
Yeah, that’s another problem, the software industry as a whole is horrendously bad at getting requirements right.
Windows terminal is a shit show. The dev blogs posts are all about useless features such as image background while fundamentals like unicode input are still broken.
My mouse would start lagging whenever I “moused” over an active Windows terminal window, in spite of running a brand new system with a 3070 GPU etc. Did they ever manage to fix that?
1 reply →
Like Windows Notepad. I suspect it was never designed for anything more than trivial cases, and then it never got requirements overhaul later in subsequent versions of Windows.
5 replies →
I think a significant contributing factor is that management is a local maximum.
I am a self-identified "sort of knows what they are doing" (albeit, sometimes insecure about that) professional programmer. I've also had the chance to take a leadership position. So, I think I have a useful perspective here.
The amount "I" can accomplish in a leadership position is so much higher than by coding directly. So, on the margins, it's really hard to justify time spent coding, compared to coordinating others. It's incredibly easy to imagine stagnating as a coder due to not doing very much of it. Yet, clearly when everyone follows this route, software quality suffers. I don't have any particular solutions.
Perhaps eventually the rate of expansion of programmers will slow, and we'll end up with too many sort of knows what they're doing" programmers for everyone to move to management, so people/companies will start waiting until programmers hit the experienced mark to make the leap.
Maybe everyone needs their ansi.sys moment though. Back in the early 1990's, I, and probably half the programmers using DOS, rewrote the dos ansi.sys driver/TSR because its was _SLOW_. mostly IIRC because it was calling the BIOS text output, but also because it was a pretty solid implementation of the ANSI terminal/esc sequence "standard".
So, the first half took about an hour or two to handle output (just write a character at the right location in the framebuffer) and get the INT/TSR boilerplate right. Then for the next 20 hours fight with all the edge cases the cropped up with corrupted text in various TUI programs that were calling the DOS string functions. Then as the size+perf approached NANSI.sys (http://www.kegel.com/nansi/) give up...
Learning experience.
> Based on my limited anecdotal evidence, it seems to me that the software industry doesn’t value technical excellence as much as it values having warm bodies report to you. This in turn limits the amount of experience an average programmer working on these big projects will have, just because they are incentivized to leave the hands on implementation work for some sort of a leadership role as soon as possible.
+10000. This is so true. It's not just that people are incentivized to leave hands-on work. Every level of the management genuinely believe that a senior engineer should not spend much time on hands-on work but instead should focus on "tech leadership", which in a big company means going to meetings, influencing other teams, writing white papers, and of course "coordinating".
From the linked article itself, I can attest to the constant push to move up into 'leadership' roles, particularly in some companies. I have stayed and worked as an engineer for 37 years. I have been 'team lead' a half dozen times, but never a full manager role. Why? Because I would be a poor manager. I have personally experienced managers that where technically brilliant, but not good at managing (or inspiring) the technical staff. They should have remained as engineers/scientists. Some corporations used to have parallel paths for technical staff that had management level pay and benefits, but the suits in the 'C suite' have eliminated that for the most part over the last twenty years. Bell Laboratories (now a shell of its former self) was once one of those places.
So in the current environment, there is constant pressure to move up or move out. Even startups are no longer immune to that. If you want to have enough shares for it to really matter in a liquidity event, you need to have a team of people below you, or at least a director level title. The startup environment in 2000 was completely different, and technically astute engineers (mechanical, electrical, software) could attract strong stock grants as engineers. That has changed. I am fortunate in that after 37 years of doing this, I am at a position where I don't even have to think about these issues any longer. I feel sorry for younger engineers breaking into the field, the management pyramid is such a PITA.
And back to the topic of strong technical engineers that are poor managers? If you get stuck into one of those situations, constant micro management, constant downward pressure of "you don't know what you are doing", get out. Find a new position elsewhere. Good managers will coach you when you need help, but will let you do your own work. Good managers will help identify your deficiencies but also guide you to work that plays to your strengths. Good managers will provide you opportunity for growth. I learned this early in my career, blessed with having an awesome manager. Since then, every job I have had, first thing I did was figure out which managers were good, and which ones were not, and made sure that I never had to work under a bad manager.
So you can make a career in engineering, but it has to be a choice, and you have to learn to manage your managers.
Also note, while I recognize that I would be a poor manager (for various reasons), mentoring is a different skill set. If you are a senior engineer, take every opportunity to mentor a starter in the field.
This seems like giving up. The article is right about the problems but seems temperamentally opposed to actually fixing them. Number of people under you is a terrible metric in many ways, but it is at least objective (ish) and hard to fake; so is years of experience. If you take the position that programming skill requires years of particular kinds of learning and there is no way to assess whether someone with x years on their CV has actually done y years of that kind of learning... well, maybe that's true, but what's the actionable takeaway from that?
I don't disagree. That said, the first step in solving a problem is to understand that there is one and what are its root causes.
EDIT: I think sometimes to goal of some prose is to be thought provoking, i.e. to allow us to find somebody else who perhaps will find a better solution if only they had been stimulated enough to care about a problem
When you interview a line manager and he boasts that he led a team of 100 engineers, do you question that he could have done the job with 10 better-picked engineers?
You get what you measure. If you reward bloat, you get train wrecks.
Hm... It's totally okay, to not be able to do it. Nobody can know everything. Doesn't mean you are in a "lower" category compared to your colleagues.
Okay, it's not a global problem (ie. "needs PHD") but just a personal problem (ie. "I have no clue how to solve it"). Trying to get as much stuff done as possible, I've said similar things in the past, though. Not really thought about it before typing. Happens...
Nobody got hurt in the process, right? Let's forgive this little misinterpretation and move on.
Nobody here seems to be focused on the specifics of the case. But i think moving on would leave a great opportunity to re-evaluate corporate SE choices.
At the very least we can agree its a good thing that the dev was able to fork/re-implement the tool with the given API.
But for me it raises the larger question. How useful is this form of software engineering management?
The tool is relativity simple enough to re-implement ( Which is a good thing ), but at the same time an entire team/governance structure was put in place to act out a set of motions, without pushing what is possible.
To be blunt, it sounds miserable to have to work like that.
> the software industry doesn’t value technical excellence as much as it values having warm bodies report to you.
One of those can easily and objectively be measured, and the other one can't.
Various orgs have tried to measure financial "value", imperfect in and of itself, but then face serious problems attributing that to individual developers.
Fundamentally, discussing "good" software is performing subjective evaluations against subjective criteria. There's no easy route out of that.
The problem with the excuse parade is, that it has to justify itself. They have to be special, the avant-garde, selected through countless interviews to live well inside the castle. If some wandering apprentice can outperform them, the hot air escape from the "rockstar" developer, wrestling with complex code sitting inside the compound of a FAMG firm.
Then nothing remains, but embarrassed silence. And the question, why this people are paid for, if they waste the customers money, aka performance of the customers computational platform and the outcome is so sub-par. Which is why they are sitting all in one huge meeting today.
I work as a mining engineer and in my eyes these stages are effectively the same as the author describes in the software world. I'd even argue they apply to most "professional" careers.
I remember a post Msoft Dev wrote about adding a fairly simple feature to a web api. The code itself could be written by a single dev in a day or two, but the logistics needed for testing, documenting, supporting and communicating this involved hundreds of people with thousands of man hours. It also would bind them to maintaining this feature almost indefinitely. Because of that last point alone it took months to years to get a signoff on features.
Most of the industry seems structured to keep devs at an intermediate level: resume-driven hiring, ageism, proliferation of open source that prioritizes easy over simple, little discussion of software design, complete lack of education/resources to move devs past that, and incentives that push people into management.
Another thing I realized when writing this: where do experienced devs congregate? (It isn't Twitter.)
> A few hours later another programmer came up with the prototype of a much faster terminal renderer, proving that for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking.
I read through the Github issue and can't find the prototype mentioned here. Can anyone link the PR/code if they know it please?
Here you go: https://github.com/cmuratori/refterm
FWIW he wrote it on the same day @Microsoft locked the issue to prevent further posts by non-Microsoft people.
I was curious as well, I dug a bit and I found this:
https://github.com/cmuratori/refterm
I think he just went ahead and created a completely different terminal.
Also, some background, the original raiser of the PR is Casey Muratori, of Handmade Hero fame:
https://www.youtube.com/channel/UCaTznQhurW5AaiYPbhEA-KA
https://github.com/cmuratori/
https://caseymuratori.com/
Whatever the comments from both Microsoft and Casey Muratori about particular details of their implementations, Windows lacks a terminal like Linux Kitty (there's an unrelated Kitty that's just a fork of PuTTY).
And by that I mean speed and features. Kitty is fast and a joy to use, and it is the software I miss the most when I am using Windows.
I noticed that when you propose a new idea, often there is no shortage of resident "experts" giving you hand-wavy reasons as to why it can't work, won't work, etc. I kind of feel like you DO need a PhD just to have enough clout for these kinds of people to trust you.
In other news: https://github.com/microsoft/terminal/issues/11405
My company hired a number of PhDs. They were all smart and well educated but for some reason couldn’t turn that knowledge into working software. So they were all fired in less that a year.
This story should be pinned somewhere for all to see.
Other example of slow performance in MS is file system access and process creation.
fwiw, file system access is kind of a bad example - it's slow because the design allows people to hook into it. once you've made promises to end users that limits the kinds of optimizations you can do and how far you can go with those optimizations.
For one example, if you were to make file I/O bypass antivirus software in 'performance sensitive cases', few enterprise admins would accept that. That performance optimization would be disabled in a millisecond. You can do directory exclusions, but some of the I/O still has to go through the filter to be checked against the exclusion list.
i swear half of this is sunken cost fallacy of cs educations
Which half?
Nice ending by the way.
There are a couple claims/assumptions in the article that feel weird to me.
1. The article derides those using "years of experience as some sort of a badge of knowledge", yet keeps on referring to "experienced" programmers as if they were better. Maybe it's terminology, but in my experience (no pun intended) there's no useful correlation between the time one is writing software and their ability to tackle hard problems. "Experience" seem to matter much less than talent, imagination and passion.
2. Article says "Sitting in an office and shuffling papers around for a decade doesn’t make you a master programmer. Writing software does." -- writing software for a decade really doesn't automatically make somebody a master programmer. The author states elsewhere in the article: "I believe your self interest and curiosity matter more than the years spent writing getters and setters". So, which one is true? As mentioned in the previous point, I tend to think the latter.
3. The article mentions "the vast majority of software is written by the ones who are still learning the ropes" as if it were a bad thing. It really isn't, in fact this is the only way people can get "experience" in a growing industry where junior devs outnumber senior devs simply due to how large the industry has grown over the past ~40 years. It has everything to do with exponential growth in the software industry and has nothing to do with programmers going into middle management and leadership roles.
4. To make sure software is competently written even if most of them are written by junior devs, the managers/leads have to make sure everybody is assigned tasks that they can handle, perhaps with supervision by a more senior/skilled dev. The job for the tech lead is to figure out which is which, and ensure that the critical parts are competently dealt with by appropriately skilled people. This is a skill that requires competence and experience. Unless you have an endless supply of senior devs, you definitely want to "distract" the senior developers from their implementation work and put them in charge of this work.
5. Article says "the experienced programmers will take care of the design problems, but that is not going to save your bacon if the implementation of a great design is terrible." -- this is of course true if you have a team of truly terrible programmers, but not necessarily true if they are just "mediocre". Design decisions include choice of language and architecture (and sometimes process), and some demand more of the developers than others. There are ways to isolate bad implementation with clean(ish) interfaces, so that "big ball of complicated code" becomes small balls of bad code that can be fixed up bit by bit.
6. This is one of the most confused claims in the article: "If you want to produce a high quality software, you also need enough experienced people in the trenches that are not merely delegating the orders from the ivory tower." The only way this can work is if you only hire "experienced" people and reject all junior devs. Because in the author's ideal world there's really no place for junior devs. They can't be mentored because that will distract "experienced programmers" from the real work in the trenches. They can't be groomed for management roles because then they can't become "experienced programmers". It really sounds like to me that the author doesn't really know how to properly manage junior devs in a team and simply assumes that if "experienced programmers" who have kept writing software in the trenches were able to keep writing software, then the result would automagically not suck. I don't think the real world works that way, not until the software industry collapses and only the best programmers are able to keep being employed.
In all it feels like the author was trying to sound insightful by stringing together a story that, at best, is just pointing out that "experienced programmers" are better than "wet behind the ears" without providing a suggested solution, and at worst, making up superficial narratives that doesn't really hold up when you try to poke it.
Sure, for every senior dev taking on management or mentoring duties, the team loses out some quality man-hours on coding, but that is presumably a positive trade overall, or people would stop doing that. The only way to keep "experienced programmers" focused on coding are: don't hire junior devs, don't mentor junior devs and don't let technical staff enter management. I'm pretty sure that's not what the author tried to say, and unless I'm missing some obvious solution pointed out somewhere, the whole point of the article seems to be spinning a flamewar from github into a sentimental narrative that doesn't lead to any conclusions..
Such an interesting case. We need to encourage respectfully disagreeable people like the developer who raised this issue. A less disagreeable person would have stopped pushing after receiving the GitHub feedback regarding how complex the problem was.
tldr; common sense.
Peter principle
It's a shame that engineers commit their time for free for the benefit of multi billion corporation. Why do they do it? These corporations are not your friends.
I think you will like that:
https://github.com/cmuratori/refterm/issues/17
Is there an aggregator for “coding drama”? Because this was all very fun to see.
1 reply →
Puzzles me. It’s ironic you give stuff away as “free software” for “the masses”, you are just helping the Pandora papers mob get richer. Unless that software is genuinely disruptive. Tor, BitTorrent for example. But that’s more rate. Memcached, Redis being free just helps corporations really.
Maybe because they are working with people, and treat them as people. After all corporations are made up of human beings.
On the one hand you have idealists who think the most important thing in the world is getting the last bit of performance out of every program. On the other side you have businesses who don't care too much about performance of their applications (especially when no money can be made out of it) as long as 80% of use cases are covered.
Whichever side you sympathize with, it's pretty arrogant to think the other side is completely wrong.