Big Data
We've got lots of data, but we're not the only ones. Think about CERN. The keep gigabytes/sec for 10s of Pb per experiment and they run multiple experiments a year.
Recent Posts (page 67 / 71)
Meetings
Meetings. They're a part of life, and with teams spread across 3 time zones, 5+ buildings and a test track, meetings with at least one person not in the room are common, almost the norm. Some are great, some are terrible, and most are kind of mediocre. Unless you're that one person who's remote. In that case great meetings are like unicorns. We've heard about them. Some of us have even been in them, but they're rare, All hope is not lost though. Here are some tips for making hybrid and all remote meetings work better.
What's In A Name?
http://journal.stuffwithstuff.com/2016/06/16/long-names-are-long And that doesn't even touch the use of acronyms and tribal knowledge.
Asking Good Questions
Here's a handy checklist for asking coding questions. It's targeted at StackOverflow and non-realtime questions in general, but the list applies to asking questions directly of someone else as well. The better you understand and can explain your question the more likely you'll get an answer.
SESE Or Not?
Single Entry Single Exit or not. Here's two viewpoints. Return Early, Return Often and Are You a Hacker or a Designer?
Lego Design Sprints
I have no idea if this is a good idea or not, but LEGO.
Things You Should Never Do
An oldie but a goody. I sure wish there was a part 2, but at least we've got part 1.
Lint
Linting has come a long way. I
first used PC-Lint back when it was new and it was valuable back then. Today linters do a lot more than look for
strangely placed ,s that change the meaning of a statement. Today, a list
of common
issues found/reported by Intel's PVS-Studio.
Python Vs. Go Vs. Rust
Python vs. Go vs. Rust. https://www.nicolas-hahn.com/python/go/rust/programming/2019/07/01/program-in-python-go-rust/ Discuss
Code Reviews
A big part of a developer's life. They can be a great way to get a broader perspective on the code you've written and suss out hidden gotcha's others know about. They can also slow you down. Multiple iterations, arguments over style vs substance, or just waiting for someone to take a look. There's lots of anecdotal evidence (user dreams/nightmares) on the topic, and even some more academic publications. Starting from the idea that code reviews are worthwhile and we want to make the most of them, how do we avoid some of the perils? Here's a couple of articles on that provide some guidelines.
