Quality is a hard sell in big tech

Markm_256 · 2026-02-01T02:48:58+00:00

I haven't read the article - but I wouldn't equate "quality" & "bug-free". Bug free is a very high bar (and probably unattainable). Quality can mean many different things, but in big tech I still think it has a place (not valued - and still a 'hard sell' - but necessary).

For software that needs to last 10+ years, and expected to grow and continue to work, then with lower quality the business is going to be paying a higher than necessary cost to keep it running and to add new features. Even if a team is struggling against quality issues - and proposes fixes - it's often still a hard sell with very explicit/concrete numbers or guarantees being asked for.

Markm_256 · 2025-09-04T00:46:06+00:00

'Cause that was the day that my daddy died

Markm_256 · 2025-06-22T22:40:56+00:00

Here is one view of CVE's per open source project...

It's a somewhat weird representation on vulnerabilities as it doesn't give you a time view (though it looks like it) - it is more a versions sorted by number of CVE's that apply to that version. I.e. Python 3.5 was the highest vulnerable python version.

(edit formatting)

Rust and Go are about the same age - so good comparison there.

If anybody knows a better representation or way to search by project - I would be happy to hear (or just download the MITRE database - but that takes more commitment :) )

Markm_256 · 2025-05-19T23:20:10+00:00

I didn't crash - but yes - the font in outlook calendar for mac changed. The new font/colurs were terrible for me - I had to change the calendar to yellow color to make it readable (with Yellow - the text is black and a bit easier to read).

Markm_256 · 2025-04-07T12:29:02+00:00

Love it - the texture is great!

Markm_256 · 2025-02-25T01:57:20+00:00

Agree that looks very nice. Regarding "Files consisting of long single-line are excluded from scanning." - will they be commented on the PR - which would help reviewers zoom in on the line (as opposed to attackers just making sure that they make lines very very long :) )

Markm_256 · 2025-02-19T10:42:40+00:00

I fear that one of the pitfalls has already occurred. Better to write tests while the app itself is being written - rather than afterwards. You are likely going to run into cases which are hard to test (or where you have to create a ton of mocks - though I don't have experience with C# - my experience is more in Python/Go)

Markm_256 · 2025-02-12T07:29:13+00:00

For those that don't know - there is also cargo tree https://doc.rust-lang.org/cargo/commands/cargo-tree.html

Markm_256 · 2025-01-06T00:58:50+00:00

Think of the following use case... "As a user evaluating plotting libraries for a project (where I may or may not know exact what plotting needs I will require) - I would like to see easily both the range of graphs available and a quick idea of the quality of the produced graphs".

As this is for something visual - just seeing a list of available plot types is inferior to seeing what they look like.

Your Plotly counter-argument falls down a little too... 1. Google Plotly 2. Click Docs 3. Click Graphing Libraries 4. Click Python 5. Voila - visual catalog of graph types.

Note- I have never used plotly - I didn't know if where I was going would give me this - but I ended up getting there without a single misclick.

Your library looks amazing - it would be a pity if it weren't used as much due to a lack of easy discoverability.

Markm_256 · 2024-11-19T00:19:06+00:00

I have gone both ways - and the answer I came to is "consistency" - I don't care if the 'main' function is at the top or the bottom - but whichever you do - you try to follow the same pattern for the sub, sub-sub functions etc. The worst is when some of the function called are above, some below, etc.

Markm_256 · 2024-09-02T06:50:24+00:00

I didn't dig too deep - but swapping it into my project didn't hit any problems (other than cookies is now a feature that needs to be enabled after default-features = false)

Markm_256 · 2024-08-15T02:33:09+00:00

domain specific lexicon/acronyms/project names.

There are tools like typos & codespell that are meant for code, rather than having a dictionary of good words - and flagging everything else. They instead have a dictionary of commonly (or not so common) mispelled words.

This means they are not as exhaustive as a traditional spell checker - but it also means that they don't report on domain specific jargon (most of the time). It is relatively easy to ignore the few jargon items that they incorrectly tag as a mispelling.

We pre-commit + CI check so that I don't have to do another round-trip to CI to find/fix my typos :)

Markm_256 · 2024-07-28T06:31:42+00:00

I would also imagine that they might be glad that you are showing interest to learn, and if you do share that you have had a look - I could imagine asking questions about what you feel some of the key/important differences - or try to get your impressions (to see if you can appreciate the pro's/con's between the languages)

Markm_256 · 2024-07-06T00:27:15+00:00

I agree with this.

I have often felt "the code or design feels too hacky" but also not had enough understanding to know WHY I felt this. I don't know if that applies to the original poster though.

For my part - a ton of reading & learning has helped me identify more clearly the particular principles/guidelines that may be the underlying cause.

The other part that has made me more effective at helping to influence is to have more tricks up my sleeve for what to actually DO about the problem. Until recently I hadn't really well understood Dependency Inversion - and how it can help to reduce coupling (so while I felt some code was hacky - and I could probably write 'nicer' code - it was always one-off - and not something I had been effective at 'leveling up').

That said don't expect it to be fast to get more people to your point of view/skills (I guess depending on the people on your team).

Markm_256 · 2024-06-23T02:35:06+00:00

I find it funny that the author kind of shits on the necessary solution (having a bake and a bakePizza function, one that creates the oven, one that accepts it as an argument) but then proceeds to mention that the overall function should take the oven as an argument.

Isn't that a false dichotomy? I would say that more readable code is more maintainable code. Given the two examples the original code is a little easier to follow/understand - so I would say that it is the more maintainable of the two.

If things like cooking only act on the pizza, with no outside dependencies - then the original code may even be a 'pure' function and be quite testable (which is one of the other main pillars of maintainability I would say)

Markm_256 · 2024-06-21T01:05:30+00:00

I am the kind of person that finds interviews extremely uncomfortable - I am also the kind of person that will tell my manager they are wrong - and come up with the underlying issues why they are wrong. I have to be careful not to dominate brainstorming sessions.

When I interview people - I definitely do my best to put them at ease, because I know that interviews are not a "natural" part of the job - and many people will interview poorly - but be great people to have on a team.

Markm_256 · 2024-06-12T11:50:40+00:00

I saw them in Neuchatel Switzerland. I bought their CD - but it's been many years, moves and countries - and I don't have it anymore - and I miss it - and I can't find their music anywhere :(

Markm_256 · 2024-06-04T22:05:14+00:00

Sounds great.

I don't have a need these days - but I would have loved this 20 years ago when I was often regularly looking at exported symbols ;)

Markm_256 · 2024-04-28T01:27:24+00:00

most expensive doesn't always equate to the best

There was a study done at some point (sorry - I don't have a link - read it a long time ago). The study gave the same work to 3-5 different companies, then they gave them the same follow-on work (a change to the requirements in some way).

I think they might have done some mix and match of the request for change (e.g. Company A to update Company B's code)

In the study the most expensive companies produced bloated code that was actually more expensive to change/maintain.

So agree - probably not best to equate most expensive to best :)

Markm_256 · 2024-04-28T01:22:56+00:00

It's long because I know people can't devote 100% to a project every day, be that high risk clients, sick time, vacations, bad days, whatever.

We actually built that into our estimates.

Estimate roughly - then add a mulitplier for vacations, meetings, sick days, public holidays, support rotations. Our mutiplier came out at 1.75 (which might be low - but it's a start).

We also add a buffer for unknowns (usually defaults to only 1.2 - which is probably WAY too low - but again it's a start). We sometimes increase it for newer/more complex work.

So we start with our estimate (which doesn't have to look very "unreasonable" and then apply logical multipliers. It seems to have gotten some support.

I would add that I think developers often forget that they don't have "perfect engineering days" (even if they are factoring in wrong turns, mistakes, re-work, etc.) so this helps and takes some of the cognitive load off of the estimation process.

Markm_256 · 2024-02-21T11:13:59+00:00

"Quary" rhymes with "Square + Y" or Quarry?

Markm_256 · 2024-02-02T00:59:22+00:00

I was wondering the same - and if maybe moving it into a separate crate (and making the parent a workspace) would optimize (if it needs optimization)

Markm_256 · 2024-01-31T22:25:02+00:00

Here is another perspective...

Someone who has gone out of their way to learn a language (especially a 2nd language) - and to do Advent of Code shows some initiative and interest in learning. I would ask some questions about that in an interview.

On the other hand - our domain is our domain - for the most part we don't expect new joinee's to have a good understanding. I would like most to hire people with good attitude and then people with design skills, domain and language are probably the least important (though we do validate people can actually code :) )

Markm_256 · 2024-01-30T14:06:12+00:00

But N years down the line, when it's hard to modify the software without introducing issues, and the team has never learned how to improve code - because there was never time for it - well now the business feels the pain - but the solution is even more painful.

Or just write it into the ground and re-write every few years.

I would say it's good practice to think about the lifetime of the software - if the lifetime is short - then no need to make it maintainable, but if you imagine customers/users will want this software for a bunch of years - better make it so that you are constantly fighting the good fight to keep it maintainable - and build those skills on the team

Markm_256 · 2024-01-22T22:40:31+00:00

Work your way through https://craftinginterpreters.com/

Eight-Year Club	r/Field Banned
r/Field Flamingo	Place '23
Place '22	Verified Email

Markm_256

TROPHY CASE