lysdexic

joined 2 years ago
MODERATOR OF
[–] lysdexic@programming.dev -1 points 2 years ago (1 children)

Non profit doesn’t mean they earn nothing

You need a valid business model to keep an organization ticking. Staff doesn't live out of hopes and dreams. It's hard enough to get a for-profit software company to stay up. If your starting point is that the company is not focused on getting a profit then it all sounds as hopes and dreams instead of an actual business plan.

[–] lysdexic@programming.dev 1 points 2 years ago

I’m not sold on user replaceable phone batteries, but USB-C was a long time coming.

As someone who had a perfectly fine Android smartphone die because its battery went dead, and had to replace it with an off-brand one to keep it ticking... I can assure you that the lack of support for user-replaceable phone batteries is forcing people to throw away perfectly good hardware.

[–] lysdexic@programming.dev 4 points 2 years ago

From the announcement:

Another frequently mentioned feature in this series is Git’s “partial clone” mechanism, which allows interacting with a repository containing a limited subset of its objects.

Has anyone tried partial clones yet? If you did, how was the experience?

[–] lysdexic@programming.dev 1 points 2 years ago (1 children)

There are parallels to be drawn between licensed professionals (like doctors, CPAs, lawyers, civil engineers) that they all have time under a professional and the professional then signs off and bears some responsibility vouching for a trainee.

We need to keep in mind that the main value proposition of these licenses is to bar people from practicing. There is no other purpose.

In some activities this gatekeeping mechanismo is well justified: a doctor who kills people out of incompetence should be prevented from practicing, and so do accountants who embezzle and civil engineers who get people killed by designing and building subpar things.

Your average software developers doesn't handle stuff that gets people killed. Society gains nothing by preventing a software developer from implementing a button in a social network webapp.

[–] lysdexic@programming.dev 2 points 2 years ago

I agree, Compiler Explorer is indeed a far better product which single-handedly popularized a killer feature.

[–] lysdexic@programming.dev 6 points 2 years ago

As a counter balance to that though, interviewers need to understand what they are hiring for and tailor the questions asked to those requirements.

This does not happen. At all.

Back in reality we have recruiters who can't even spell the name of the teck stacks they are hiring for as a precondition, and asking for impossible qualifications such as years of experience in tech stacks that were released only a few months ago.

From my personal experience, cultural fit and prior experience are far more critical hiring factors, and experience in tech stacks are only relevant in terms of dictating how fast someone can onboard onto a project.

Furthermore, engineering is all about solving problems that you never met before. Experience is important, but you don't assess that with leetcode or trivia questions.

[–] lysdexic@programming.dev 6 points 2 years ago (1 children)

to add to this, id like standardization of qualification and competencies - kind of like a license so I don’t have to “demonstrate” myself during interviews.

I strongly disagree. There is already a standardization of qualification of competences in the form of cloud vendor certifications. They are all utter bullshit and a huge moneygrab which do nothing to attest someone's experience or competence.

Certifications also validate optimizing for the wrong metric, like validating a "papers, please" attitude towards recruitment instead of actually demonstrate competence, skill, and experience.

Also, certifications validate the parasitic role of a IT recruiter, the likes of which is responsible for barring candidates for not having decades of experience in tech stacks they can't even spell and released just a few months ago. Relying on certifications empower parasitic recruiters to go from clueless filterers to outright gatekeepers, and in the process validate business models of circumventing their own certification requirements.

We already went down this road. It's a disaster. The only need this approach meets is ladder-pulling by incompetent people who paid for irrelevant certifications and have a legal mechanism to prevent extremely incompetent people from practicing, and the latter serves absolutely no purpose on software development.

[–] lysdexic@programming.dev 10 points 2 years ago (3 children)

We spend so much time building devices that are meant to break, and be unfixable, and making software that fights the user instead of helping.

Kudos to the EU for forcing mobile phone manufacturers to support replaceable batteries and standardize on USB-C charging.

[–] lysdexic@programming.dev 2 points 2 years ago (1 children)

(...) so more open standards and just Web apps instead of proprietary apps

What do you classify as "proprietary apps", and from the user's standpoint where do you see a difference between them and web apps?

[–] lysdexic@programming.dev 1 points 2 years ago

You can always find a new shitshow

Having to deal with different volumes and types of shit can be a very welcomed move. Perfect is the enemy of good.

[–] lysdexic@programming.dev -2 points 2 years ago* (last edited 2 years ago) (1 children)

If it’s not constant at you may get the loop invariant movement. But only if the compiler can tell that it’s invariant.

The point is that if the predicate is evaluated at runtime then the compiler plays no role because there is no compile-time constant and all code paths are deemed possible.

I suppose what I should have said is more like “in many cases you won’t see any performance difference because the compiler will do that for you anyway.”

I understand that you're trying to say that compilers can leverage compile-time constants to infer if code paths are dead code or not.

That's just a corner case though. Your compiler has no say on what code paths are dead if you're evaluating a predicate from, say, the response of a HTTP request. It doesn't make sense to expect this hypothetical scenario to be realistic when you have no info on where a predicate is coming from.

17
CMake Guidelines (developer.mantidproject.org)
 

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

Noted software expert Robert C. Martin, presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin, who has helped bring agile principles from a practitioner’s point of view to tens of thousands of programmers, has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of software craftsman, and make you a better programmer―but only if you work at it.

What kind of work will you be doing? You’ll be reading code―lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly you will be challenged to reassess your professional values and your commitment to your craft.

Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code―of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.

Readers will come away from this book understanding

  • How to tell the difference between good and bad code
  • How to write good code and how to transform bad code into good code
  • How to create good names, good functions, good objects, and good classes
  • How to format code for maximum readability
  • How to implement complete error handling without obscuring code logic
  • How to unit test and practice test-driven development
  • What “smells” and heuristics can help you identify bad code

This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.

view more: ‹ prev next ›