beny23

Wait what?

> put down a returnable deposit of .157 ETH (about $400)

and

> Users receive $50-$100 a month worth of the token

Isn’t that the definition of a pyramid scheme?

Also

> Extremely high transaction fees—sometimes higher than a month’s worth of UBI—also make it hard for UBI users to take money out.

Oh so your initial deposit is refundable but you have to pay a quarter in fees if you want to take money out.

And

> We want to use the wealth and incredible power of the blockchain to to really address social problems like poverty or marginalization

But isn’t taking $400 upfront (when 2.6 billion people live on less than $2 a day) the very definition of exploitation?

The solution to the energy crisis is to use much more energy. Makes as much sense as burning more fossil fuel to solve the climate crisis. What that’s what’s going to happen there too!

Maybe you won't need to: https://arstechnica.com/gadgets/2022/01/google-relents-legac...

No.

I'm a software consultant with a consultancy that would qualify as both high paying and remote in the UK and involved with interviewing, personally I value having a "homework" assignment so that candidates can complete a simple assignment and then build on that in a pairing session.

I don't think much of leetcode assignments as they tend to focus on the algorithm and getting solution through rather than writing good quality code that keeps it simple and is maintainable. That is much much more important than repeating an algorithm.

Though I also would say that in the current climate, the pressure on finding good candidates is so that a lot of places are considering dropping take-home tests in fear of putting off quality candidates, so I think you may well be in a good position at the moment to avoid leetcode and hackerrank...

But Julian Lennon will keep the physical items…

I AM OFFERING YOU THIS OPPORTUNITY TO OWN AN NFT OF A SUITCASE FULL OF $1,000,000 IN UNMARKED BILLS. I’ll keep the money obv…

I’ve made some edits to emphasise that I’m not against blockchain/crypto tech per se but that it’s the energy consumption of bitcoin in particular that concerns me. Thanks for all the feedback

Absolutely not :-) But sitting on my hands and saying “this is fine” didn’t sit right with me. If it triggers the odd conversation about “should this use so much energy” - then I consider this a win. Personally I’ve learned that there are centralised networks (XRP) which are much less power consumptive.

Fair point on the criticism of lumping all cryptocurrency into the same pot as bitcoin. Will add an edit later. Thanks for the feedback!

So how come the energy consumption is still bigger than all but 22 countries on the planet? Saying that other coins don’t have the problem doesn’t make it ok, no?

thank you for your feedback, it certainly was not my intention to lump everything together - can see where you're coming from and will look to do some refinements/edits to the article after doing more background reading. I just got frustrated with the feeling that the waste of energy appears to be accelerating. I've got no beef with blockchain per se, but it's the colossal waste of resources that gets me.

I feel a bit “we value processes over people” on this one. Not disagreeing with a lot that’s said but it just feels a bit prescriptive and I think agile (as in manifesto rather than big consultancy) is very much context specific

Of course the same applies not just in the field of maths. The same could be said about software engineering just swap “projects” for tickets…

I agree with the sentiment. Too often does the idea of agile get replaced by a top-down we-replaced-project-managers-with-delivery-leads-and-want-to-micromanage-everything version of agile that some of the rituals but none of the autonomy. I think big consultancies and SAFe snake oil merchants are to blame there.

Though I try to be optimistic and don’t think agile is dead. If the right people use the right ideas it can be beautiful to watch (from the inside and from without). I don’t think there are any hard and fast rules as to what is agile and what isn’t. Like very much it depends on people not written down processes. Many a time have I felt that just following the ceremonies blindly or having everything written down in stories doesn’t make sense (a side effect of doing agile via an expensive agile consultant trying to impose process on an unwilling team).

When it’s driven from the bottom up and supported from above, it can work wonders.

If waterfall is the first Death Star is SAFe the second?

> Know what people are asking you to be an expert in

I read this as “leave it to the experts and please realise that sometime it’s not you” which is something that is sometimes quite hard for micromanaging delivery leads or business stakeholders when it comes to implementation details. Worst is when there are endless progress update meetings about some some irrelevant detail that then holds up the whole project.

Similarly it is quite difficult for developers to realise that leaving design decisions to user researchers and ux designers is a good thing!

> Cryptocurrencies give us the opportunity to create new financial instruments that do not support industries that are destroying the environment.

While crytocurrencies’ ridiculous hunger for energy will destroy the environment all on their own.

How much energy is wasted or could otherwise be used mining the next whatevercoin.

Speaking from experience, if you have to go back after many years of development, where most of the team that made the original design choices has left and want to make changes without breaking the system and discover that half of the system has no tests then it’s going to be difficult to even make the smallest of changes.

When you then decide that you need to retrofit good tests, it always becomes an exercise in trying to reverse engineer the requirements (because half the documentation has been lost or is so hopelessly out of date it may well be lost), then yes, making something well tested is very hard.

Having said that, it often worth doing it because how else are you going to have the confidence that you don’t break the system with every little change, but it very much is going to require much more effort than if it had been done in the first place.

Yes that’s what I meant

Ok, my bad for “I think” - I should have said: in my 30 year experience I’ve yet had to come across a system were good tests were a hindrance to performance. I’ve had many a time where complex investigations into performance problems were uncovered by systematic and automated tests.

If performance is a main goal, then surely TDD with performance in mind will give you a better advantage

I think that the “we can go quicker by not testing” is a fallacy. If you do TDD right it will make you quicker, not slower in the short term. Not just the long term...

I’d argue that getting performance in a coupled unstructured mess (I’m not saying that’s what SO made) is going to be more difficult.

It’s always going to be orders of magnitude more difficult/expensive to retrofit testability. I’d argue that they were successful despite their approach not because of it.

I actually have a lot of time for their design choices (monolith, scale up as much as possible, etc, not everything needs to be distributed microservices) but to find doing that by sacrificing testing is surprising.

I really don’t think it’s a model to follow.

Oh absolutely, keeping things simple should never be restricted to just production code. Testing code should be simple too.

The idea that tests inhibits refactoring I find problematic though. Good tests enable refactoring. If the tests are too complex for anyone to change the code, the the code is too complex. Any complex system should be composed of simple components. Now this applies to monoliths as well as microservices.

I agree it is easy to fall into the trap of thinking that tests are boring though as devs become more experienced there should be less of that thinking, hopefully.

In my opinion, the idea that you can have well-tested code OR performance is tosh.

If you don’t have good testing and do it regularly how can you refactor your application for speed if you’re not going to be sure that you’re going to introduce a regression?

And I think the stackoverflow team know it:

> Currently, we’re trying to change this. We’re actively trying to write more tests and make our code more testable. It’s an engineering goal we aim to achieve, but the changes needed are significant.

This makes it sound like a lofty goal but I think it just sounds more like. “Oh crap, we’re sitting on a mountain of tech debt”

No I know you can’t always expect to arrive at a project and find the sunny uplands of TDD and continuous delivery but if you do get to “optimised for speed” code (to me that’s a synonym for tech debt that’s slowing down delivery) all you can do is slowly add what should have been done in the first place (tests).

Was it due to an intern?

It is very easy to write code that “works on my machine” or “works in QA” and then fails when it hits production volumes or a requirement changes to add more users/elements.

Then it often becomes prohibitively expensive to just throw more servers/VMs at it.

And often the “expensive” engineer changing a nested loop into a map lookup can save years of compute time in a matter of hours.

Unfortunately all too often that only happens after scaling up/out without understanding why systems are slow.

Don’t get me wrong, I’m not arguing for needless early optimisation but an inefficient query/algorithm can waste a lot of computing resources...

I’d be a bit sceptical about JSON everywhere as it would mean throwing out all the shell tools and everything having to parse JSON which seems overkill.

I think the clarity and brevity of this is amazing. Should be mandatory reading for teaching to people starting in computing.

I’ve always thought that the concept of piping input to output and the shell is on of the most powerful “programming environments” around and to see its origins is humbling!

I think the general idea of finding people who take pride in a job well done is a sound one and does often mean the difference between success and failure of a project/business.

Where the article completely falls down in is how to measure “giving a shit”. There’s plenty of people that work long hours, get rewarded well but ultimately just create mess after mess that someone who cares about clean, simple code then cleans up after them.

A culture that just values attendance is most likely going to have a negative impact on the motivation. I remember a situation where a delivery lead shouting “nobody leaves the office before this bug is fixed” leading me to question the values of a client.

Don’t get me wrong, I don’t think that gimmicks like pool tables in the office and slides make an iota of difference to someone that gives a shit about software.

What does make a difference is a culture that encourages initiative, values transparency and pragmatism. These are the kinds of things you want hear when being interviewed. How many hours did you work will/should turn the real talent away...

I have an intuition that COBOL will become very valuable in the years to come as the majority of greybeards that keep it running will stop work - and then the projects to rewrite core business functions in banks, insurances will come think and fast and will provide a never ending gravy train for contractors that can help with migrations or keeping the lights on. I for one have COBOL on the list of languages which I want to know enough to understand.