[deleted]
Be Less Technical
61–70 of 73 posts
Re: Be Less Technical
#62Well-put. I participated in a protracted comment thread several weeks ago about the use of 'number' in HTML input field 'type' attributes. The problem was inexperienced HTML writers using 'type=number' for phone numbers, order numbers, social security numbers, account numbers, etc. The resulting interface elements— e.g. increment/decrement— are designed for elements like quantities and are more harmful than helpful with those more common uses.
I argued that in general, people are perfectly correct in calling telephone numbers, order numbers, account numbers, social security numbers, etc. "numbers" regardless of how a computer handles them. I also argued that the purpose of HTML was to describe data rather than how it should be handled, and that argument is to describe formatting rather than a data type. I asserted that a general-use term like "number" was wrong for a field with such specific use cases obvious only to developers.
Personally, I think the shakiest part of my argument was asserting the purpose of that label. To my surprise, others only argued that labelling those other things 'numbers' was not accurate in general because computers didn't treat them like numbers, and supported the current label 'text.'
OED definition 3a for number: > An arithmetical value assigned to something or someone, esp. to indicate position in a series, or for purposes of reference, identification, etc.
There is no definition for 'text' in the unabridged OED that describes anything other than words.
English is a descriptive language and software doesn't override that. Most people see a collection of numerals with punctuation and think "that's a number" and that's clearly how we use the term in regular language. "Order Number" and "Telephone Number" (3b for 'number' in the OED) are not colloquialisms. The most common uses for fields those developers would consider 'real numbers' — e.g. quantity— don't even have the word 'number' in the name.
I don't even expect most developers to intuitively recognize how these ingrained shorthands differ from the rest of the world, but we MUST NOT instinctively dismiss indicators that our perspective isn't representative. We're making the tools modern folks use to solve many of their problems and we stand to make their lives a lot worse by assuming our use cases, language, challenges, and perspectives are the same or more worth considering.
Re: Be Less Technical
#63Where I work now, it's a shitshow. To a (technical) outsider who wasn't with the company when they built everything, the original requirements and constraints are not obvious. The solution was lazily built in an ad-hoc fashion, so requirements continuously emerged out of the need to work around the failings of some other foundational system that was badly implemented. Suddenly you're being asked for a zero latency re…
This is indeed a big challenge for seniors hires. They are expected to understand the domain, product, and business context to create impact in little time.
I experienced this myself twice, failed miserably once and just about hung on second time. I've also seen quite a few senior ICs being let go within 4-6 months because they just couldn't get their head around the mess.
The obvious response of "document everything" hasn't been useful where I worked. Either company didn't embrace them or they got out of date in short time. I just don't know how to tackle it beyond putting in hard grunt work to understand the system.
Re: Be Less Technical
#64Thought train: - What are the first principles of communication. - Of what you want to say, what can they hear. - The more refined (technical) your knowledge, the fewer people there are who can understand it. - "Language is the interface for describing problems." This phrase makes me rather happy for some reason. - Do you want to sound clever, or be clever. (It's easier to sound clever.) - What are all the functions…
> Filtering technical knowledge into a relevant format for a listener to comprehend in real time is a skill that can be learnt. Sadly, not a skill most "scientific journalists" appear to have learned. There's a difference between "make understandable" and "dumb down to complete context-free drivel"[1]. And that's before the aforementioned "journalist" takes a single press release from a university PR department at fa…
My understanding of what might be going on here is broken telephone with intent. A reporter gleans only a subset of information from a given body of research, then ends up reporting only on what portions they consider to be essential. The end result loses nuance and context.
I don’t think reporters want to be doing this, but society doesn’t incentivize serious reporting in of itself.
Re: Be Less Technical
#65Where I work now, it's a shitshow. To a (technical) outsider who wasn't with the company when they built everything, the original requirements and constraints are not obvious. The solution was lazily built in an ad-hoc fashion, so requirements continuously emerged out of the need to work around the failings of some other foundational system that was badly implemented. Suddenly you're being asked for a zero latency re…
> Documentation as code, man In my list of mean things I'm going to insist on should I ever go crazy and start my own company, documentation will be just as if not more incentivized than the actual code. I want design diagrams, users lists, documented decisions on how backups are expected to happen, how this is expected to scale, why we went with X pattern instead of Y, who asked for a given feature, then as a last m…
One of the things that has struck me as ironic for people who like to call themselves "engineers" is how resistant to documentation some software developers are. I understand and have experienced all the problems with documentation taking time and how easily it can get out of date, but when I look at what other engineers do when they need to modify a building or structure, they immediately go to the blueprints that tell them how the building is put together, where the structural support is, where the wiring and plumbing is, etc.
I guess those can just as easily suffer getting out of date, not updated with small changes, etc. but at least they provide a picture of how the thing was built in the first place, a picture that is still helpful for understanding.
Re: Be Less Technical
#66Where I work now, it's a shitshow. To a (technical) outsider who wasn't with the company when they built everything, the original requirements and constraints are not obvious. The solution was lazily built in an ad-hoc fashion, so requirements continuously emerged out of the need to work around the failings of some other foundational system that was badly implemented. Suddenly you're being asked for a zero latency re…
> Documentation as code, man In my list of mean things I'm going to insist on should I ever go crazy and start my own company, documentation will be just as if not more incentivized than the actual code. I want design diagrams, users lists, documented decisions on how backups are expected to happen, how this is expected to scale, why we went with X pattern instead of Y, who asked for a given feature, then as a last m…
Careful with that wishlist. Design diagrams can quickly go out of sync with reality, and with no loop of responsibility to keep them up to date. In other words, brittle. Some artifacts are relatively timeless (like "Why we decided in 2018 to do X") but others are not.
Re: Be Less Technical
#67Earlier quoted context omitted.
I've found Lightweight Architecture Decision Records (as markdown docs in a repo with the code, or wherever makes sense) to explain the current landscape, options, decision, and foreseeable consequences. Keeping it really light makes it tolerable for people who don't like to write docs, though does need the team to insist on the doc for anything non trivial. I also like using the Draw.io vscode extension to draw diag…
I push for plantuml sequence diagrams for almost any new feature. Keep the files in SCC and can review with the MR. Most engineers find them useful and not too much of a headache to write.
Back when I did these sorts of doc tasks for a prototyping team, I used to create BUML* using Visio. It was kind of hard but nowhere near as hard as using Rational's offering. The dev team liked and used them. I like the looks of PlantUML. Thanks for posting about it.
* Bastardized Universal Markup Language.
Re: Be Less Technical
#68Well-put. I participated in a protracted comment thread several weeks ago about the use of 'number' in HTML input field 'type' attributes. The problem was inexperienced HTML writers using 'type=number' for phone numbers, order numbers, social security numbers, account numbers, etc. The resulting interface elements— e.g. increment/decrement— are designed for elements like quantities and are more harmful than helpful w…
yeah, i suppose it should have been called type=amount
Re: Be Less Technical
#69I have a phone call with my stepmom most weekdays. Part of the call always involves discussing what we plan to do for the day. She’s very impressively technical about the things she’s interested in, but our areas of expertise have very little overlap. I find it rewarding for both of us, and a really good mental exercise to “explain it to my stepmom” and find we both share some understanding at the end of the conversa…
This was my telephone life with my Dad for thirty years, all of his later life and almost two thirds of my life, even well into his dementia (because his memories of his professional career were really untouched by it). After only one month I already miss it enormously. I am very glad you find these calls rewarding and I am certain she does too. I am going to have to find someone to fill this role in my own life agai…
I’m terribly sorry for your loss. I very much appreciate your reply, and I hope you find the person you want/need in this role.
If I may be presumptuous as a stranger who’s grieved several special relationships to offer advice, please try to catch yourself if that pursuit/search feels like it’s looking for a substitute for your Dad the person. Whichever relationship like that comes next will be both familiar and unusual. It might still be worth pursuing even if it doesn’t feel right at first.
Re: Be Less Technical
#70Earlier quoted context omitted.
I don't really think of dumbing it down, more like distilling it to its true essence. To be able to do so requires even more skill and understanding than just enumerating the details. I always think of the Feynman anecdote where he talks about skipping chalk on a chalkboard.
I tend towards the view that I do not understand any given thing until I can teach it.
I wonder how strong of a signal that is for a good engineer. There have always been people who've stood out as wanting to teach, wanting to mentor. Is it too much of my own bias to say that good engineers are good teachers?