Things to say when you're losing a technical argument (2001)
web.archive.org
web.archive.org
I like your idea. Why don't you write up a white paper and we'll review it at the next staff meeting?
I sent it, then continually followed up on the status of the points made. Some changes ultimately did get integrated because of it, I think calling the bluff forced someone to actively read, think, and respond to it, even if it wasn't leadership, they had someone else spot check and agree/disagree on points.
I think that it requires acknowledgment that there are two sides to such issues; as someone who is on the side that typically ends up having to handle the majority of the busy work to get many proposal through in my company I absolutely want the proposer to make the effort to figure out the stakeholders/costs/challenges for their project as well as answers. I'm willing to __fill in gaps__, but I don't really want to be having to do the basic legwork for someone else's project.
I don't mean to sound like I want to stifle inconvenient creativity; it's certainly not the case, and when someone has really taken the time to make some new tooling/project with benefits and acknowledges the costs involved, I'm more than happy to champion such projects.
But when someone just has a desire (or disparagingly, a whim) to change stuff up because it simplifies their workflow and they expect someone else to handle all of the communication of their project without even giving me the courtesy of doing such research, I cannot deny I approach such proposals negatively as I feel a bit used and I think that the expectation is "I want this, make it happen", which is not my job.
Similarly, I find myself encountering persons who expect that I and the rest of the company will magically intuit the importance of very niche projects without being willing to take the time to simply explain the pain point they wish to address. I'm not even talking about deep technical details here, but simple things like:
"We spend N amount of time on task X"
"I have an automation workflow that will require Y hours to implement, but N is reduced by Z [time value]"
Instead, the presentation is "I want to implement this automation workflow; what do you mean explain the value? Can't you see it? Why are we so caught up in corporate bureaucracy?"
I'm all for reducing N as much as possible, but if I myself can't explain why spending Y is vastly cheaper than N, I have no confidence in my ability to convince others that the cost of Y is worth it.
I've truly been on both sides, and it is some work to justify a change, sure. Formal proposal documents are a bit much for my taste, but whether we like it or not, C-Levels aren't going to read your code and they definitely aren't going to read a 2000+ word stream-of-consciousness email describing the project in an unstructured way (much less any git readme.md files). The impetus is on the person proposing the change to at least make an effort to convey the reason for the change to the relevant stakeholders.
Requiring some basic rigour to the thinking is good though.
Since time can only be spent once, you are essentially picking between a quick&dirty prototype and a nice document.
The document invites a bikeshedding session and consumes reviewer time, the prototype often allows you to immediately see whether the idea is worth pursuing, it may directly deliver a part of the benefit of the completed solution, and most importantly, it'll show the actual weaknesses in the design and the real constraints you have to deal with in a way that a theoretical review can't.
One could answer, "Sure, but that will take away time from current things that need attention."
Its not a bluff, it is a way of weeding out the non-serious requests.
If you take the time then so will I.
Its not a bluff, when the point is to weed out the ones, who aren't willing to actually do a written proposal.
context: design docs are frequently written at G.
At one of my jobs, we wrote design docs for most major changes (we had a checklist for deciding if the doc was necessary at all). It was ultimately quite helpful because documentation about most important changes existed, even if the dev didn't write any documentation in code. The technical designs also had a template, so it was a fairly easy path for a developer to know what questions to answer or not in their doc.
Is this the same idea as a white paper?
I advise other engineers, especially those early in their careers, to actively develop and hone their communication skills. It deserves far more focus than most people seem to give it.
The appear to be an artifact of a policy, the problem they solve is 'not having a design document' and nothing more.
We all tend to get a lot of ill-thought out pet ideas about what needs to happen in a project. Even a tiny informal doc listing out what problems you're actually trying to solve is a massive boon for communication.
I like the discipline of writing these out for myself, I like reviewing them, and I like being able to look back on them for my own past projects as a way to quickly warm my mental cache.
Just let me know what you want to learn, how you hope to use it, and what you've tried in the past.
kthx
* Background
Background on the problem we’re solving.
* Design Goals
Requirements and goals of the project. This should also include numbers like traffic assumptions, usage, uptime requirements, etc.
* Other Proposals
Options that were looked at, but we evaluated that weren’t going to work
1. Option 1
2. Option 2
* Solution Summary
Summary of the solution in a paragraph or two.
* Solution Details
Details of the solution...feel free to add/remove sections that make sense, some starter ones are below.
* System diagram
Diagram of all the binaries, databases and 3rd party services that this system touches
* Wire frames
Any wireframes for the UI if this has a frontend component?
* Code
Where is the code going to go? Does this touch any common repos? Any new repos being created?
* Testing
What kind of testing is going to be done. Unit tests, regression tests, etc.
* Scaling
What aspects of traffic do we need to think about for scaling. If the traffic goes 10x, we ok? could the database grow 10x and cause issues?
* Operation details
Details that the operations team might want to know like location of binaries, monitoring to be setup, oncall, etc
* Internationalization
Do we need to think about spanish?
* Tradeoffs made
Write out the big tradeoffs made
https://web.archive.org/web/20051224054905/http://www.joelon...
If that was helpful, then please donate.
Maybe it's just me, but this sounds quite heavy.
I do this all the time, sometimes even something as simple as asking the user to write up the request in an email is enough for them to go away forever. It's a simple way to check if the requestor is invested in the request, or just trying to slide something from their to-do list to yours with zero effort...
Management hated that, and to this day I don't get why. I recognize the need for things to be reviewed by others, and we all can lose scope of what's important sometimes. I'm no exception. However, for things that are purely technical/scientific arguments, what's gained by me having to use the Official Template (tm) to propose an idea, and spending days messing with words and bullet points, rather than a demo that you can see with your own eyes?
It also struck me as quite hypocritical. On the one hand, professing to have a "bias for action", then on the other hand harshing on people for preferring action over another TPS reports.
See also: CIA memo "How to Infiltrate an Organization and Make it Dysfunctional" grin
There's a subtle but important thing to note here. My bet is management didn't hate that you did a POC. They hated that you DIDN'T also do a writeup.
It's not about this vs that. Meet the minimum requirements before you go doing extra.
The documents are hard specifically because not you have to consider alternatives, or the feasibility of executing. What security concerns did I cover? How much time do I need to spend convincing team y to add this feature?
The demo is always the easy 50%, and never the hard parts that cause you to spend two years building alignment and executing.
A demo is no substitute for a written proposal and vice versa. The first is empirical, the latter is analytical and deliberative. Each has its proper place. Really, the demo is a way to corroborate the proposal, so it's a question of how rigorous the proposal needs to be. Some minor tweak might only require a quick discussion while a deep change will require deeper consideration.
If your argument is any good, then all this whitepaper would do is make a better case. Asking for a whitepaper is not a bad thing for ideas that require some careful consideration. They're overkill for trivialities that can be fully decided here-and-now and or for things that don't really matter.
Too often have I seen developers running in circles chasing ideas that could have been ruled out with a little forethought and analysis. They'll respond superficially to some idea that tickles their fancy, waste a bunch of time implementing it only to either realize that it's a bad idea, that it has serious drawbacks, or better yet, leave everyone with a dreadful piece of garbage to maintain.
> They're overkill for trivialities ... and or for things that don't really matter.
I think you answered your own question.
I wanted to ask him if he got his copies of Apache/Mysql/php/Redhat on government stamp paper. Instead, I quit two weeks later.
6D Chess: set up an LLC to do this, and convince the place to buy the discs at significant markup.
Such a person should be at least capable of understanding the modern concept of how something like a .deb file is authenticated based on its hash from the public gpg keys for the debian package server in question, or the equivalent thereof for redhat/centos.
On the other hand, I bought the most expensive version I could ($139 vs $49 or $79, just to throw some money Redhat's way)
I would have loved to hear any technical excuse
Having "I'm an asshole" tattooed on his forehead would have been less noticeable. We should all be so lucky that interviewees give such clear cut signals.
I once fell in this trap. Almost two months researching competitors to a solution I had proposed because a coworker proposed something else. At the meeting to present both solutions he was fiddling on his phone and when asked his thoughts after my presentation, just replied "yeah, it's fine".
Key is to find minimum required effort.
No one is allowed to propose something without first proving that they did the homework or that there is a need to even consider what they are thinking.
"The artifact may have dependencies and we're analyzing those now, Sir." Especially useful when you've upgraded and it all goes to hell.
Those damned artifacts will get you every time.
I used to do that with a friend at my first job. We'd argue for hours until we found a good solution. The joke, of course, is that everything before then was stupid.
Of course, this assumes goodwill and friendship between the arguing parties. There is nothing wrong with losing an argument when a better solution exists.
Oh so this is where some people in the Go community got their main argument against generics...
>It doesn't. That's just a "template" file, which I use search and replace in order to generate the three monomorphized go files.
>If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier.
Things to Say When You're Losing a Technical Argument [2001] - https://news.ycombinator.com/item?id=7982845 - July 2014 (2 comments)
Things to Say When You're Losing a Technical Argument (2001) - https://news.ycombinator.com/item?id=1440999 - June 2010 (21 comments)
Giving this a go on my next argument XD
2) Thank you.
I get the rest of the references, but what is a Be obsession? Also the last one is gold
Put out of business by everyone's favorite monopolist, but to some extent it lives on as Haiku: https://www.haiku-os.org/
> BeFS -> Matador
Was Matador a code name for APFS, or is this something else entirely?
Pops was a graphic designer so got to grow up with that evolution and consolidation of the various programs that all eventually were either subsumed or put out of business by Adobe (and I guess MS).
There are still competing programs existing in the margins -- iWorks is obviously still around, and there are some other word processing apps hanging in: Nisus Writer for the Mac and Nota Bene for Windows have both managed to persist since the 1980s, although they're both pretty different programs than they were then. And Adobe definitely has competitors in indie shareware these days, like the Affinity applications. (And of course there's open source competitors like LibreOffice, GIMP, etc.)
(Oh, and QuarkXpress is still around!)
But is it multi-cloud?
"That isn't PEP8"I really like this one - would anyone care to make a suggestion for a modern replacement for Windows NT here? Perl 6, perhaps?
we all had to take a basic programming class at the beginning too, but that was like when moses was a baby cruising down the river.
do beginning programming classes still start with BASIC/Pascal? i'm assuming boot camps don't, but do typical programming classes skip over them entirely too now?
I don't think people learn Pascal nowadays. And basic (whatever capitalization, prefix or suffix you add) is dead.
Various teachers and school systems find that Pascal/Object Pascal is superior for introducing and teaching programming concepts. We have to keep in mind that part of the reason that Pascal was created, was to teach it in schools. But don't get confused (as some detractors try to make it seem Pascal is only for academic purposes), as Turbo Pascal and Delphi show that Pascal can be successfully used commercially too.
There was quite some controversy years ago, when South African schools switched over from Java to Delphi. The school system felt that Delphi/Object Pascal was the better choice.
To get a taste, check out Mr Long Education's (a teacher from South Africa) Delphi/Object Pascal YouTube channel below (there are a number of similar such Delphi/Object Pascal YouTube channels) https://www.youtube.com/user/MrLongEducation/videos
Probably the most well known, that many programmers would know off the top of their heads, is "Why Pascal is Not My Favorite Programming Language", written in 1981 by Brian Kernighan. There were many more similar short "hit jobs" written like it.
What is overlooked by many people is that Brian Kernighan worked for AT&T/Bell Labs (and didn't retire until around 2000). He was an advocate for C and friends of Dennis Ritchie and Ken Thompson, co-creators of the C language. Sorry to digress a bit, but Ken Thompson would later on co-create Golang (Go), which many argue shows a strong Pascal influence.
Brian Kernighan's assessment of Pascal was very bias, and should have been taken as such. Instead, it was "weaponized" as a way to disparage and discourage use of Pascal, even 20 to 40 years later. Even though: 1) Many of the negatives stated in his papers became no longer true as Pascal evolved as a programming language (to include Object Pascal/Delphi descendants). 2) What he stated were negatives were not true for various versions of Pascal around even the time of his paper being published. 3) Some of the things he described as "negatives" at the time, turned out to actually be positives about the language. Probably a good idea to take a look at the below link to get a better idea of various points: https://wiki.lazarus.freepascal.org/Why_Pascal_is_Not_My_Fav...
Microsoft was the other major player involved, because it could be described that it went to war with Borland (including using dirty tactics), in order to squash it. Particularly Turbo Pascal, various products of Borland, and trying to derail the company. This includes hiring away Borland's top engineers to work for Microsoft, and among their biggest pilfered treasures was Anders Hejlsberg (the creator of C# and Turbo Pascal).
Even today, in various C family language circles, there is unfounded and unthinking dislike for Pascal/Object Pascal/Delphi or anything not using curly braces. Despite that the language is a very good and viable alternative to C, C++, Java, or C#.
My point was that even if one deems Pascal an inferior language, they can't deny it has a complete set of control structures so experience of programming in Pascal is transferable to other languages.
My own contribution would be: *) This would violate Accessibility requirements
It's easier to just not be wrong /s
I cackled pretty hard at this one.
Help! Can someone explain this one to me, just so I can use it with some context.
It seems like an underhanded way to stifle technical debate.
You used to program in Pascal, didn't you?
Oh my god, I'm a terrible person!!
:)