blog/content/links/20200526.md

+++
title = "Links for 2020-05-26"
date = 2020-05-26

[taxonomies]
tags = ["links", "recutils", "git", "cobol", "paying", "open source", 
"free software", "contributing", "boring stuff", "accessibility", "great code",
"steps", "joel spolsky", "culture tests", "microsoft", "oil companies",
"marketing"]
+++

GNU Recutils, Tips on Git, Simple COBOL Code, Paying for Open Source,
Contributing to Open Source, Dealing With Boring Stuff, Accessibility, 12 Not
So Great Steps For Great Code, Culture Tests, Microsoft Marketing.

<!-- more -->

## [GNU Recutils](https://labs.tomasino.org/gnu-recutils/)

So you want to keep a simple database, but don't want to go through the loops
and hoops of creating a script to manage it? Worry no more, the solution is
here!

Recutils is a set of tools that I wasn't aware it existed, but it keeps
information in plain files, allow searching and has a schema.

## [5 Useful Tricks You Didn't Know for Git](https://densitylabs.io/blog/5-useful-tricks-you-didn't-know-for-git)

While I'm not a huge fan of the short logs/changes (just "not a fan", not
saying it may be useful), the `whatchanged` and the other commands are pretty
damn useful.

## [A basic "game" in COBOL for learning](https://github.com/BasiliusCarver/TicTacTOBOL)

Ah, the good old days of COBOL. Haha, who am I kidding, they were never good,
that's all we had!

But if you never saw a COBOL code, here is a taste of it.

## [Paying for Software](https://www.paritybit.ca/blog/paying-for-software)

We have seen this discussion going around for some time, but it's worth
repeating it: In an age of large usage of free software, we must remember that
companies making money with it are not helping fund said software.

But it's also worth mentioning that not every free software needs support.
Going "Open Source" is, sometimes, a marketing plot just to get visibility;
I've seen companies making open source in which they _never_ heard the points
raised by the community itself and even just focused on new features, leaving
the bugfix part to the community (and no, I'll not cite with company/software
does this).

## [How to Contribute to Open Source Software](https://killalldefects.com/2020/01/26/how-to-contribute-to-open-source-software/)

I have a presentation on the "Why and How to Contribute To Open Source
Software" (it's in Portuguese, so I won't link it here), but here is a 
complete explanation on how to contribute with software -- and yes, there are
more ways to contribute than just writing code.

I like how very "step by step" this post describes how to do it, even if it is
focused on a major service and may not reflect all open source projects (I may
even "steal" some of those for my presentation).

## [Help, I can't learn/do something because it is boring!](https://letterstoanewdeveloper.com/2019/09/23/help-i-cant-learn-do-something-because-it-is-boring/)

I've done my fair share of boring stuff -- I sadly remember when I have to go
through 30+ AWS Glacier folders to restore one single file on each, with the
interface not allowing me to open each folder in a new tab, so it was _really_
boring: click, click, click, click, wait, click, click, click, rinse, repeat.

But, if I could, I'd automate the heck of it, and I probably should have taken
some breaks -- which was hard, considering my boss sat in front of me.

## [Standards for Writing Accessibly](https://alistapart.com/article/standards-for-writing-accessibly/)

Some tips on how to write interfaces in an accessible friendly mode. And while
you may think "Why should I worry about accessibility when only low-percent of
users have a disability?", you may also wonder how many of those have a
_temporary_ disability, like they just came back from their LASIK surgery,
they broke their arms in a ski accident and so on. Providing accessible
content for people with disabilities may also improve your interface for those
people -- and they would probably be grateful that they don't need to check
your competitor.

## [The Joel Test: 12 Steps to Better Code](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/)

An old post by Joel Spolsky, but it is probably worth repeating. This is a
checklist of things you should do for better code. But we need here to discuss
if the whole list is actually good.


I've seen a lot of projects fail 'cause it misses something incredibly simple
like specs, so devs keep running in circles, trying to figure out what
actually needs to be built.

On the other hand, some things feel out of place, in my opinion:

- Having an up-to-date schedule is good for business, but it could also blind
	those people from the "most viable product". In my experience, having a
	schedule is ok only on high level, but most of the time is makes people
	focus on previously though deliveries and not on what is being built.
- Having the best tools money can buy is awesome for developers that like the
	latest shinning thing (and hey, I do like it too), but it's not totally
	necessary. You can have the "most ok tools" and still be a heck
	productive.
- Having testers is not something I'm fond. Not that there is something wrong
	with tests -- quite the opposite -- but I'd prefer to have test
	engineer/designer than testers. Why? Because it should be the developers
	testing the system, building automated tests when necessary and specially
	'cause writing those would give more understanding of the whole.
- Having candidates to write code is bollocks; asking candidates on their
	thought process for solving a problem is _a lot_ more effective. Sure, you
	could do both, but think about the time the candidate will take for
	writing the code, then thinking on how to improve it, while they can
	simply describe it for you. "But it's their time"; yes, and you're just
	being an asshole if you thing their time isn't worth shit.

Honestly, when I picked the link in my feed, I though "Hey, that's a good list
of things to have". But then I started writing this and noticed how broken it
seems. 

## [The Pragmatic Engineer’s Developer Culture Test](https://blog.pragmaticengineer.com/the-developer-culture-test/)

Instead of the checklist above, I think this makes more sense, even if its
results can only be verified in the long run -- and the Joel list seems more
focused on the short.

It's way more focused on the culture part of the company, what culture the
company is trying to build and such -- and as someone who suffered a lot under
micro-aggressions without realizing, and without _my boss_ realizing, it
surely stroke a never there.

## [While Microsoft Was Making Its Climate Pledge, It Was Sponsoring an Oil Conference](https://www.vice.com/en_us/article/xgqypn/while-microsoft-was-making-its-climate-pledge-it-was-sponsoring-an-oil-conference)

This is from January this year, but I decided to share it 'cause it shows
something a lot of companies do: "We Are The Good Guys" in marketing, "we
don't actually care" in business.

I've read some other stories like this: Promote the Pride March, but ignore
harassment on LGBT+ people inside the company; say you are here to help, but
close repositories and make a contract with ICE. On and on and on.

Just to make the point clearer: This is not something "Microsoft" does, it
what every big company does.

---

This post was built with the help of

* [Jake Bauer](https://social.paritybit.ca/@jbauer)
* [newsbot](https://mastodon.social/@newsbot)
* [HN Tooter](https://mastodon.social/@hntooter)