Thread by @colmmacc

Tuesday Tweet Thread time! Today's is special. 5 pieces of programming advice: write tests, think in data structures, learn functional programming, check everything and bail on bad, and use "why" not "what" comments. Plus a small totally open $1,000 programming contest. O.k. ...

First a disclaimer: I've been programming for over 30 years, and for 20 years on mission critical systems, and these are thoughts from that and from observing and helping beginners, but there are many paths to walk, and no single perfect way to program. Find what works for you!

O.k. so my number one top tip for programming is to write tests, and to really really deeply value testing, and not think of it as a nuisance or a burden. We all get a satisfying high from that eureka moment of making something 'work', but that's not 'done'.

If you're just learning to program, do this early. Even "Hello World" can have a test, and it's kind of a travesty that programming books and tutorials don't do this! If you're into your career, think about taking a time period, maybe one day every week, just for writing tests.

If you begin or lead a project; spend a lot of your time on how to make integrating and writing tests easy and even pleasurable. There is *nothing* that pays off more in my experience ... and it's a great way to really differentiate and develop yourself too.

Write unit tests, write integration tests, write regression tests, get into formal verification, make tests super fast, integrate them into your build or continuous deployment system.

Remember that tests are the hallmark of professionalism. For software developers, they are the equivalent of double checking if the bolt is tightened.

Next tip: Think in data structures! It can be too easy to fall into a trap of becoming a programmer that works in a specific programming language, or to rely on copy and paste, or StackOverflow. It's more than worth the push through to really understand what's under the hood.

That means learning about data structures and algorithms, which is hard! But it's easy to begin ... learning how arrays work is a start. And hashes, and trees, and more. It's incredibly exciting stuff when you get into it.

Here's a really simple example from s2n; using arrays to parse and emit base64. github.com/awslabs/s2n/bl… See how much cleaner that is than something that uses a lot of "if"s?

Get into the habit of being able to break problems down into data structures. As if data structures and algorithms are lego blocks. Programming languages are just an implementation detail, not actually the real programming.

O.k. item THREE ... learn functional programming. So you are simultaneously very unlikely to use functional programming "for reals" in a paying job, and yet knowing it can expand and change your whole approach.

FP is great for stretching your mind and helping you form deeper abstractions around code. The idea that functions are data ... awesome. Recursion. Immutability. Declarative programming styles. Composition. We are spoiled with riches!

Every big program I've designed has been heavily informed by these concepts. The core memory management of I/O of s2n uses all of these ideas .. even though it's written in C. github.com/awslabs/s2n/bl…

Read SICP, learn about Erlang, look at FP features in Javascript and Rust. All super super worth it.

O.k. item FOUR ... check everything and bail on bad. What do I mean by this? I mean every time you call a function, a library routine, or whatever ... check for errors! don't mask exceptions. Anticipate "that shouldn't happen" errors.

If there are invariants that should hold in your program, check those too! You can pretty much never check things too much. And if things don't add up .... bail! Be very very defensive in your programming.

This also relates to a simple programming tip. It can be easy to fall into a pattern of ...

if (condition1 == good) {
...
if (condition2 == good) {
...
if (condition3 == good) {
do_something();

but this is bad and becomes dangerous.

Instead do:

if (condition1 != good) {
bail();
}
...
if (condition2 != good) {
bail();
}

if (condition3 != good) {
bail();
}

usually makes context much clearer, avoids nesting confusion, and builds in that pattern of bailing!

o.k. last piece of advice and it is ... don't write "what" comments, write "why" comments. If you have to comment on what your program is doing, then the code itself was not readable! Instead use comments to provide context.

Use readable variable names that are nouns and meaningful function names that are verbs. The code doesn't have to be poetry, but it can absolutely be easy to follow. Give your future self an easier time. Code is written to be read.

Very very rarely there is code that can't be easily read; if you're using bitwise operators as part of cryptography or compression or something, for example. Comment those with a "WTF is this doing" ... be very very verbose. But that's the only exception I've found!

Which brings me to the $1000 programming contest! 3 prizes: $500, $300, $200 for the most readable, easy to follow, tested, Apache Software License 2.0'd, implementation of @lemire's nearly division-less RNG. lemire.me/blog/2019/06/0…

@lemire I hope he doesn't mind because I didn't ask! I've chosen @lemire's algorithm because it is awesome and ground breaking, very short, and intrinsically hard to follow if you're not into the math.

@lemire His blog post contains a 14 line implementation in C, and there's also a paper getting into it: arxiv.org/abs/1805.10941, so there's great material to start from. But how can we make it more readable and easy to follow for a beginner or non-math-expert? how can we test it?

@lemire Have at it and give it a go! Any programming language you like. Apache Software License so that it can be included in other things. Closing date: September 1st 2019.

@lemire Message me a gist, or a link, or send me an e-mail, whatever works ... and we can talk readability and testing about it too!

@lemire For further reference: here's my rejection sampling RNG implementation with more comments than code. github.com/awslabs/s2n/bl…

End of thread!