HN user
Coding things since '85...
Had. Now we have the "Merit Order Principle". Cheap energy (i.e. renewables) are used first but the price is determined by the most expensive energy source running. (See https://de.wikipedia.org/wiki/Merit-Order)
So if you're running a solar park you have production costs of about 5ct/kWh. But if there's also a gas plant running you get maybe 20ct/kWh. Instaprofit.
But why should I put my time into reading and thinking about your article if you didn't think it worth your time to actually think about and write it?
Hope the Next Big Thing (TM) is the Electric Monk.
Makes me wonder how much information from prehistoric civilizations got lost by cutting up their libraries into wedding rings...
One aspect of humor depends on cognitive flexibility. Puns work that way.
So if you're not able to make the right mental context switch at the right moment, you won't get the joke.
It's difficult to reason about intelligence in this context.
Human intelligence is defined by behavior we humans value. Intelligence tests are geared to measuring these aspects.
Intelligence tests devised by animals would look totally different - and it's quite thinkable humans wouldn't do too well taking them.
Wouldn't assume that animals have less language ability than we humans, unless we totally figured out what other species are really talking about. Unless we do this is just an assumption.
Yes, that was clever.
But he showed real intelligence by never doing anything like this in front of us ever again. ;)
And they are able to show insight and planning to get what they want...
Once a friend of our dog came visiting, grabbed his favorite stuffy and happily chewed it in the yard. Which our dog clearly resented.
So he cleaned up the yard and hid all other toys in the house. Usually that's our job - he never bothers to look after his toys.
Then he came out with an old tennis ball, pranced around, played with it, like "Dude, this is the BEST toy EVER invented. An it's mine."
His friend dropped the coveted stuffy and came over to investigate... our dog dropped the ball, grabbed the stuffy and hid it in the house.
His friend was left with a slimy, boring ball.
I really can't think of any other explanation - he knew how to get his stuffy, but also anticipated this trick wouldn't work twice. So the cleanup in advance.
Reminded me of this interesting bird song visualization project:
https://github.com/soundshader/soundshader.github.io/tree/ma...
Less information than a spectrogram, but really visually appealing. :)
Wondering if pesticides, especially neonicotinoids play a role in this epidemic. Neonicotinoids are neurotoxic and have effects on mammals...
https://en.wikipedia.org/wiki/Neonicotinoid#Harms_to_Mammali...
A pity, I'd have liked to visit Scotland again. Perhaps it's just me, but when a country decides to treat me like a criminal suspect instead of a welcomed visitor I just don't want to go there anymore.
Exactly that - the subtitle really says it all: "A Handbook of Agile Software Craftsmanship"
A craftsman is an expert in his field who applies his knowledge and techniques judiciously, not religiously or automatically.
Really don't like the enforcing. Okay, mixed feelings there.
Rules should help you along, perhaps set a framework for your thinking. But they never should limit you in achieving your goal. When establishing a rule you should also specify what you want to achieve by it, how you'll measure its effects and under which conditions it should be removed.
Rigid rule enforcement has a strong danger of shifting the priorities of the developers to the detriment of your business.
Don't know if this is really a bad thing - had the same problems with the book, but the apparent contradictions made me really think about the stuff. So I'm quite prepared to consider his advice, I'd never turn it into gospel.
Don't think so. If the senior engineer is worth his salt he should know that programming is always about finding a balance between several aspects of a given problem - some of them technical, some of them human. As long as the code does what it's supposed to do the rest is mostly up to personal taste - so yes, you can have an insightful discussion, but there's only to learn, nothing to "win" for all participants.
but rules are important, and this is what we're missing today.
Programming rules are important - they make you think before you break them. Just don't turn rules into dogma - otherwise your devs will be more concerned with following the rules than solving the actual business problems. And you don't want that.
Just wondering - balloons aren't exactly a novel technology. And they are comparatively cheap to produce.
So if spy balloons were considered a real threat - why isn't there a more cost efficient way to take them down?
Sounds familiar, especially the stuttering. Not really sure what's going on with me, but I found that sitting down for about 10 minutes and drinking one or two glasses of water alleviates the symptoms. Might be I just need the break, might be I'm stuttering because I've been dehydrated.
There’s a lot of collaboration and spontaneous connection that happens in hallways and kitchenettes.
Those spontaneous connections yielding noticeable results are probably an urban legend. 25 years in the business and I've never seen this happen. You're talking with people in your team/project anyway in regular meetings, so there is no reason to drag that into the hallway. Talking biz to people from other projects/teams is mostly impossible - would take hours to explain a specific problem to get a meaningful contribution. Never goes beyond basic griping and commiseration.
If you think those meetings are essential for company success you REALLY should examine your process.
Quite so. As the article stated there are quite a lot of things wildcards abhor which the company needs done somehow anyway. Devs with another mentality.
But that wasn't my point in my previous comment. I was thinking more along the lines of "value for the customer" and the 80:20-rule.
I'm quite aware there's a strong correlation between code quality and the quality perceived by the customer, but if the customer didn't demand a certain percentage of code coverage or that every typo fix in a comment has to be done on a developer branch and code reviewed I see no value in these activities. So I feel more productive if I'm able to omit those steps.
Others probably think they're more productive than me because I don't get anything "really finished" by their standards.
Don't think so. For example some devs I know just love following an elaborate development process with as many quality gates as possible. Some like to glue as many complex frameworks together into a solution as possible. Some just love to do the same things the same way again and again. Wildcards don't.
A wildcard tends to focus on the problem solving and tries to cut on the fluff. So this feels certainly being more productive than dancing the process steps, striving for perfect code coverage by unit tests, nitpicking in code reviews and messing around with "cool" frameworks.
(I consider myself a "wilcard". Once joined a project for a sprint with a very elaborate development process. Spent about one hour on things I consider "work", the rest of the day was just "idling" to get this "work" past an armada of "quality gates". So yes, on my own I feel several times more productive then some process junkies while delivering "good enough" code, according to circumstances.)
It's just weird learning about interesting engineering accomplishments by news that they're gone forever...
It's more likely that orbital junk will make any space based activity impossible.
Knowledge was everything, I bought tons of books and had fun digging into the most obscure and arcane language features. Just mastering things was very rewarding in itself - gave me a feeling of accomplishment and brought the respect of my peers.
Software architecture was a thing - you were given the full responsibility for your component. Something to take seriously. And something you could take pride in, when your process was the first one to run 24/7 without crashing or memory leaks...
Work-life balance was worse for me because I spent lots of "free" time learning stuff to apply at work. Now I'm trying to do things I enjoy. Coding isn't among those things any more - Scrum and its ilk took all the fun out of that.
It might have started as a symbiosis between wolves and a species of particulary greedy and dumb monkeys which thought it would be a good idea to fleece the wolves for fur parasites.
Still humans love to pet dogs, and dogs enjoy it. ;)
Growing up with home computers DID give you a different mindset about computers. Sooner or later you realize that you can make this machine do anything you want it do do. And it was quite simple to get started.
No way you'll get this same mindset with modern smartphones.
First thing I do is cleaning up the code base. I'm deleting unused code, fix class and method visibility according to usage, do the occasional rename if naming is inconsistent, check error handling and logging for inconsistencies, write the occasional unit test... This gives me a broad overview over the code base, improves my chances to find anything by text search and enables me to better assess the impact of changes.
Read this two times, but really couldn't understand why I'd want to do this, which practical problems this is going to solve. Must be getting old...
Yes, that's totally annoying since it really isn't very hard to get right... Swings layout managers are just made to deal with this stuff.
Now we've got jlink to bundle your application with the neccessary runtime modules into one custom runtime image... a bit late to the game, but still...