Threads for Xenophon
-
I use Overcast on iOS, and listen to only two podcasts right now (both not tech related):
-
-
Tinkered with Game Maker this weekend.
Once I got over the “not twiddling raw bits hewn from stone and sweat” (and there’s certainly time for that, as I had previously made Pong in Rust), I actually had a lot of fun
The language seems to be a variant of ECMAScript. The UI neatly syncs sprites and game objects, and so I was able to follow a tutorial and make Asteroids in less than a couple hours – sound effects and everything!
-
So, instead of just collectively grumping about Uncle Bob, let’s pick out a piece of his article that’s actually worth discussing.
What do you think it would mean to be “professional* in software engineering?
What do you think we have to do to achieve (1)?
Do you agree that limiting our tools to reduce churn is a good approach? Why or why not?
-
I think choosing not to make life difficult for those who come after us is a professional trait. That may include sticking to a reduced, but standardized, tool set.
After the development phase, software projects often go into maintenance mode, where a rotating cast of temp contractors is brought in to make necessary tweaks. The time you save by building a gloriously elegant automaton must be weighed against the cumulative time all of them must spend deciphering how the system works.
-
Do you agree that limiting our tools to reduce churn is a good approach? Why or why not?
All other things equal, yes. Maciej Ceglowski [0]:
I believe that relying on very basic and well-understood technologies at the architectural level forces you to save all your cleverness and new ideas for the actual app, where it can make a difference to users.
I think many developers (myself included) are easily seduced by new technology and are willing to burn a lot of time rigging it together just for the joy of tinkering. So nowadays we see a lot of fairly uninteresting web apps with very technically sweet implementations. In designing Pinboard, I tried to steer clear of this temptation by picking very familiar, vanilla tools wherever possible so I would have no excuse for architectural wank.
I complain about frontend engineers and their magpie tendencies, but backend engineers have the same affliction, and its name is Architectural Wank. This theme of brutally limiting your solution space for non-core problems is elaborated on further in “Choose Boring Technology” [1]:
Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps.
If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble.
-
“All other things equal” is one hell of a caveat, though :)
I’m a huge fan of the healthy skepticism both Dan McKinley and Maciej exhibit when it comes to technology decisions. When something passes the high bar for making a technology change, though, make that change! Inertia is not a strategy.
-
-
2.a: Take diversity seriously. Don’t act like raging testosterone poisoned homophobic ethnophobic nits just because we’ve been able to get away with it in the past.
2.b: Work to cleanly separate requirements and the best tools to satisfy them in the least amount of time from our desire to play with new toys all the time. 2.c: Stop putting $OTHER language down all the time because we see it as old/lame/too much boilerplate/badly designed. If people are doing real useful work in it, clearly it has value. Full stop.
Those would be a good start.
3: See 2.b - I think saying “Let’s limit our tools” is too broad a statement to be useful. Let’s work to keep our passions within due bounds and try to make cold hard clinical decisions about the tools we use and recognize that if we want to run off and play with FORTH because it’s back in vogue, that’s totally cool (there’s all kinds of evidence that this is a good thing for programmers in any number of ways) but that perhaps writing the next big project at work in it is a mistake.
-
What do you think it would mean to be “professional* in software engineering?
Our stupid divisions and churn come partly from employers and partly from our own crab mentality as engineers.
They come from employers insofar as most people in hiring positions have no idea how to hire engineers nor a good sense of how easily we can pick up new technologies, so they force us into tribal boxes like “data scientist” and “Java programmer”. They force us into identifying with technological choices that ought to be far more prosaic (“I’m a Spaces programmer; fuck all you Tabs mouth-breathers”). This is amplified by our own tribalism as well as our desire to escape our low status in the corporate world coupled with a complete inability to pull it off– that is, crab mentality.
What do you think we have to do to achieve (1)?
I’ve written at length on this and I don’t think my opinions are secret. :)
Do you agree that limiting our tools to reduce churn is a good approach? Why or why not?
I’m getting tired of the faddishness of the industry, but I don’t think that trashing all new ideas just because they’re “churn” is a good idea either. New ideas that are genuinely better should replace the old ones. The problem is that our industry is full of low-skill young programmers and technologies/management styles designed around their limitations, and it’s producing a lot of churn that isn’t progress but just new random junk to learn that really doesn’t add new capabilities for a serious programmer.
-
I’m getting tired of the faddishness of the industry, but I don’t think that trashing all new ideas just because they’re “churn” is a good idea either
I agree, I completely agree. I absolutely understand that it is foolish to adopt new tech before it has developed good tooling (and developed, as someone pointed out in a comments section somewhere, a robust bevy of answers of Stack Overflow). You’re just making your developers' lives harder. Still, trashing new ideas is also silly, for a very good reason.
I think that the argument ignores genuine advances in technology. In the article, Java is likened to a screwdriver. Sure, throwing away a screwdriver for a hammer is nonsensical tribalism, but throwing away a screwdriver for a power drill isn’t. There will be times when I want to explicitly write to buffers – I’ll use C or C++ as needed. But why would I otherwise pick a language that segfaults, when advances in language design and compiler theory have yielded Rust, which may well do the same thing*?
It might cost more in the short term to tear down the wooden bridge and build a concrete bridge. Heck it might cost more in the long term to do so, if concrete is more expensive to maintain (I acknowledge my analogy is getting a tad overwrought.) But aren’t better guarantees about the software you produce worth it?
For the record, I’m not trying to speak as a Rust evangelist here – it’s just a topic I know about that fits the argument. It’s new, it’s still developing its tooling, but it clearly represents progress in programming language theory.
For another example, imagine if the people in the argument used vim. Vim is robust and powerful – but many people consider it a poor choice of tool for Java development. How would I convince this person to switch from vim to IntelliJ. Isn’t IntelliJ just another example of churn? It’s a new shiny tool, right? Thoughtful consideration of new stuff is required to distinguish between “churn” and “hey maybe we can move on from the dark ages.”
I don’t want to be accused of talking past the author. I think that the author would agree with an underlying point – that whichever language, IDE, framework you choose, you should choose with a good understanding of what your tool can do, and what the alternatives are.
*I mean, it might not do the same thing – you might want blazing speed or something else that C provides that Rust does not yet. So, yeah, choose your tools wisely.
-
-
I’m nowhere near an expert on password security, but isn’t it better practice to store passwords through hash-and-salt? Surely you’d compare the stored hash to the hash of the user’s submission.
Is this considered secure because it is local? Alternatively, are there design reasons why encryption was chosen over hashing?
EDIT: I now see that I misunderstood the distinction between password storage & management and password verification by a third party.
-
The original plaintext needs to remain accessible so that, eg, your password for Neopets can be retrieved and submitted to them when you log in.
In cases where the plaintext is not needed (for example, managing the passwords of users accessing your web app), hash-and-salt is a far better approach.
-
-
michaelochurch
7 years ago
|
link
| on:
Scrum.org hacked, may have lost crypto keys and some user data
Is this surprising, given that “Scrum” is a time-honored managerial excuse to force engineers to do shoddy piece work?
-
-
It’s relevant here. Scrum is all about shoddy, business-driven engineering… so Scrum.org getting hacked is completely relevant.
-
It is entirely possible that you are correct but people are unwilling to hear what you have to say, because of the frequency with which you say it.
You are shoe-horning this in. You really are. When I read this story, and come to the comments, I am not interested in how scrum is bad (it is) or how it is detrimental to our workforce (also, you know, it is). I’m interested in IT horror stories, which orthogonal to scrum. Maybe scrum is related, maybe it isn’t, but a site got hacked, and scrum isn’t to blame any more that scrum was to blame for Adobe getting hacked from the exact same vulnerability.
You need to listen to stig’s original reply, I do really think you’re not hearing him. This is said as someone who likes your blog and your writing style in general – I’m not looking to put you down, but to make you see what you’re missing.
You’re right, of course, that it is relevant. It just isn’t constructive. The two aren’t the same. Nor is it thoughtful, incisive, or deeply critical, which is what I expect from someone like you, or really from any user of this site.
C'mon, man. Don’t take cheap shots. Not here.
-
I considered it relevant, but I see what you’re saying. I probably made a certain leap too soon.
-
-
-
-
-
-
I don’t want to care about this. I shouldn’t have to care about this. The fact that I do care about this is really, truly, indicative of terrible design decisions.
If we’re getting specific, the decisions that made the systemd devs become blasé about changing the expected behavior of other *nix programs. But still, generally, I shouldn’t have to worry about this. And yet, I am worrying about this.
So I’ll probably go to BSD, where I don’t have to worry about this.
-
I’ve been a Linux guy since I ran the two-floppy 0.95b on my 386dx/25 running SLIP over a 9600, but last year I realized that the same forces (overwhelming popularity + eternal september + corporations + frameworkophilia) which made node.js what it is today were rapidly overwhelming the operating system and made the jump to FreeBSD. Haven’t tried OpenBSD yet, but super happy with my decision.
-
-
-
So I’ll probably go to BSD, where I don’t have to worry about this.
Do yourself a favor and try Gentoo first. The BSDs can’t really compete with Linux on the driver availability front.
-
Gentoo is great. I use it at home 100% of the time. OpenRC is wonderful, blows systemd out of the water. But I would carefully note: it is not a curated correct system, and if you are used to Debian/Ubuntu, you will need to upskill your Linux-fu. For instance, right now, I (probably) goofed something up, and now Docker won’t start, because
?. I will have to debug why the kernel module such and such isn’t being picked up properly by Docker. I don’t have to do this on my Debian machine at work. :-) -
Yeah, I tried installing BSD a few days ago and ran into an issue with my BIOS not being able to boot off the USB, so I have to agree with your point about hardware support (will probably be installing Gentoo on my main desktop computer). When I get a new laptop, I’ll probably look for something with decent BSD support out of the gate to make installing it a bit easier, since I’ve been meaning to run it on one of my machines for a while.
-
-
-
-
Finishing up my first video game with a friend. We spent the weekend implementing Pong in Rust for fun (and watching, or in my case re-watching, Marvel’s Jessica Jones), and are setting our sites on something a little more complicated next. It’s just a for-fun thing, and we are purposefully not setting timetables on anything.
Besides that, I’m trying to get back into contributing to the Rust site. I’ve got a collection of FAQ answers to add, and some other small sundry updates to make PRs for. Hopefully the end result is a slightly more useful website for everyone.
I’m also reading through Dybvig’s “Three Implementation Models for Scheme” so that I can really get started on implementing Ruse, into which I have put very little time to far.
Finally, I’d like to get a list of Rust blogs going, so people have a single place to go to find Rust things they can subscribe to. This is a first step toward getting a quality Rust Planet setup. There’s been some interest so far, but I figure the legwork is valuable even if the Planet doesn’t happen.
-
-
That’s Xenophon, with an o.
And yes. :D
brinker wouldn’t clamp down about Rust, so I thought, hey, why not. Turns out it is easier to get stuff done than I thought, given that I had previously treated Rust like Haskell, which has that stigma of “great theoretical knowledge is required to do things well.” Turns out that isn’t true for Haskell (mostly), and it definitely isn’t true for Rust. SDL bindings were straight-forward, docs were thorough, and the compiler warnings were markedly sensical.
-
Ha! Totally missed that he’d also posted.
-
-
-
I made a barebones Pong in Rust over the weekend, as a sort of impromptu game jam with a buddy of mine. It was a cool way to learn Rust, and to remind myself why I like programming in the first place.
-
This article confuses me, mostly because the author either is ignoring or is oblivious to the normal connotations surrounding the phrase “A Modest Proposal.” Or this is even more deadpan satire than I had anticipated.
https://en.wikipedia.org/wiki/A_Modest_Proposal
As I read, I was thinking, “Is he arguing against office hours? How is this satire? I do not understand.” Perhaps someone can illuminate this issue, given how he continues in his follow up. Is he serious? If he is, why did he choose the phrase “A Modest Proposal” to headline his original idea? And if he’s not, his follow-up just confuses me further as he appears to be doubling-down.
-
I think only the title, “eliminate email”, is satire. The joke is that email is so widespread we can’t globally eliminate it, and the satire is in calling such an unrealistic idea “modest”. The content is in earnest - he advocates eliminating email internally, but keeping it for external communication.
This satirical use of “modest” can be understood without knowing the history of the phrase “a modest proposal”, and perhaps the author came up with that phrase without knowing its history either.
-
-
-
Anyone else bothered by the article’s constant characterization of imperative programming as “conventional”/“traditional” and functional programming as implicitly new and weird? First, characterizing functional programming as new or unusual is strange given that Lisp, the prototypical functional programming language, was first written in 1958. Second, such a characterization serves no purpose other than to bias the reader against functional programming languages without actually making an argument.
-
No, no, no. We have the best tools money can’t buy.
So many projects I have seen derailed by….
How about instead, “Pay’s upstream devs / contributes to the best tools money can’t buy.”
There are a lot of great open source software tools, but that blanket isn’t enough to cover you. Having the best tools money can buy includes support contracts (possibly to upstream devs), service management (datacenter or various IaaS/PaaS services) and excellent dev hardware (laptop?)
This is more what I was thinking about when I wrote the article. I think that open source tools, software definitely has it’s place in engineering, and should probably be preferred in a lot of cases.
I’ve always been attracted to the idea of 80/20 time, and I know that (especially at Google) the implementation never lives up to the idea.
Still, I think that the intent is noble: give the developer some ordained “free time” to get their creativity going again. In that spirit, I think that experimenting with different development tools (IDEs or editors, continuous integration tools, etc) should be encouraged and discussed. After a milestone, as the team has a retrospective on what worked and what didn’t, I think tools should be a part of the discussion. Did Sarah discover that Jenkins is more useful than Bamboo? Hey, look, Chuck learned about oh-my-zsh, you know that sort of thing.