< Back to the archive

Like what you see? Subscribe here and get it every week in your inbox!

Issue #50 - February 16, 2020

If you are looking for work, check out this month's Who is hiring?, Freelancer? Seeking Freelancer? and Who wants to be hired? threads.

Here are the top threads of the week, happy reading!

Top comment by carapace

Not quite what you're talking about but the best book on car mechanics I ever read... It was red, and textbook-sized, hardcover. Lots of drawings.

It literally started with an explosion in a can, and then progressively enhanced that idea step-by-step: add a lid to the can to capture the energy, add a lever to keep the can lid from flying away, and then attach the lever to a wheel so that it returns the lid to the top of the can for another explosion, add walls to guide the lid, ta-da! Piston.

It goes on like that, adding each piece of the puzzle in a logical way, until you have a mental model of an internal combustion engine. You definitely feel like you could build one from scratch (if you had the metallurgy skill.)

Top comment by sevilo

Pads and tampons. Some argue these are environmentally unfriendly and produce too much waste, but you have to think, not everyone is privileged enough to own a washing machine in their own home, particularly those in 2nd and 3rd world countries. I genuinely believed pads and tampons allowed women to be more productive in the work force and eventually lead to more equality, just hearing my mom and grandma's story of having to hand wash your own bloody (literally) period bands gives me nightmares, that was in the 70s, not that long ago.

Top comment by jng

If you basically don't know how to code in assembly, learn 16-bit x86 with whichever method you find, it won't be wasted. You can extend most of the knowledge from 16 to 32 bit substituting register names ax,bx,cx,dx,si,di,bp,sp y eax,ebx,ecx,edx,esi,edi,ebp,esp. You can extend that to 64 bit with rax,rbx,rcx,rdx,rsi,rdi,rbp,rsp. Learning 16-bit x86 will have you learn about segment registers, but it isn't wasted either, protected mode consists of quite a lot of complications on segment registers, virtual memory addresses (which you can mostly ignore as an applications programmer as compared to a kernel or driver programmer), and interruptions.

I wrote a book to learn x86 programming and it was published in 1994 back before "real digital age", oriented to be the best didactical text possible (I had to learn the hard way, I wrote what I would have had to read 10 years earlier). Over 20 reprints, recommended in all Spanish-speaking universities (yeah, I know, if I had known then what I know now I'd have done it in English). It was discontinued 10 years ago or so, they asked me to revise it for the modern world, and it didn't really make sense: rewriting it for what assembly language is and is used for in today's world would be a ton of work because it's a qualitative difference, and if I added an extra chapter explaining 32-bit and 64-bit changes and letting the publisher stamp a "2010 edition" logo on the cover would just be scamming people, which I don't want to do. Here is the link to a scanned copy of the original: https://www.dropbox.com/s/sz6rinfhyc8sai6/Lenguaje%20Ensambl... . Could prove useful if you can speak Spanish.

Honestly: I learned Z80 assembly first, in the 80s, and then switched to x86 very easily. Learn whatever assembly language first, what's hard is learning about registers, flags, memory... and if you learn it will, then you can switch to another architecture quite easily.

Top comment by ganonm

I'd highly recommend reading SQL Antipatterns. It's a very approachable book that illustrates how to design a database schema by taking commonly encountered scenarios and first showing you the naive approach. After explaining why this is bad, it then shows you the recommended way of doing it and why this way works better.

I think 'learning from how not to do something' is a really powerful pedagogical technique that should be more widespread.

Top comment by crdrost

I do not have advice directly addressing your question about how to read, but I will say this:

A lot of this complex-dense-technical stuff is difficult precisely because it can get abstract. That is true for example in writing proper C for kernel development (your field) and physics (my old field) and chess (everybody's field).

My solution is to do lots of exercises and learn lots of examples before learning these big theories. Essentially I think learning is fundamentally Pain. You have to take on the pain before the learning can alleviate it, if you try to skip the pain then you have only a superficial idea of what you're talking about.

So like if I am learning Go, I am writing a command line Fibonacci calculator in it, then I am rewriting this ground-up with test driven development so that I can learn what testing looks like in Go, then I might try to build an HTTP server, then I might connect it to a database, then I might learn how to mock the database. Each of these tasks I am setting for myself needs to be answered by consulting tutorials and references, but if I just follow a tutorial I will not build true knowledge, I will just know how to do things when someone is holding my hand.

Top comment by akcreek

I have a wide-ranging self-taught skill set as well that I've developed over the last 14 years of running my own businesses. I'll share what I'm doing from a high level as it might not be the most common path.

I've been acquiring small but promising businesses that don't have the right team in place to move them forward. I bootstrap them on my own and replace my roles as the business can afford staff. Once enough roles are replaced, I'm able to start looking for the next business. I'm on my fourth business now. Sold the first two, the third is a productized service netting seven figures, and I just acquired the fourth, which is a SaaS business that I believe has great potential.

Currently, I'm formalizing this method and will build a team that can execute it much more quickly than me alone. I'll be shooting for a new business every 12-18 months to build a portfolio. We'll have a group of partners and a small staff that will be focused on getting these acquisitions straightened out and growing, then we'll install a team to run them full-time and we'll go on to the next one.

So just taking what I've been doing for years and everything I've learned from it and scaling it up to reduce the timeframe from acquisition to growth and then operation of the business.

If OP or anyone else who identifies themself in a similar manner wants to chat, email is in my profile. I'm actively looking for people like us to work with.

Top comment by ozanonay

Hi there, I'm the author. Yes this list precisely constitutes the topics in computer science on which I believe a software engineer with an informal education should focus. It's based on my experience of having taught computer science to over 1,000 junior to mid-level engineers, mostly bootcamp grads, in person in small classes over the last 5 years.

I've been meaning to update it slightly, to recommend _Computer Systems: A Programmer's Perspective_ over P&H (although P&H is still excellent) as well as Martin Kleppmann's book _Designing Data-Intensive Applications_ for distributed systems.

Top comment by FabHK

Crypto-Gram, by nestor Bruce Schneier, on IT Security:

https://www.schneier.com/crypto-gram/

Unsupervised Learning, by Daniel Miessler, on IT Security or "intersection of security, technology, and humans", interesting links frequently:

https://danielmiessler.com/newsletter/

Money Stuff, by Matt Levine, on finance, derivatives, accounting shenanigans, VC, etc., frequently very funny and insightful:

https://www.bloomberg.com/opinion/authors/ARbTQlRLRjE/matthe...

https://www.bloomberg.com/account/newsletters

Top comment by bjornlouser

We have an alumni network that any developer can ping via email. The group is comprised of former standout employees who were paid a small retainer at the time of departure in return for their commitment to provide missing details and lore about design choices, missteps, and implementation.

Top comment by mcintyre1994

I really like Wes Bos' courses, they cover full stack Javascript and some other FE stuff if you're interested in that. https://wesbos.com/courses/ is his list of courses.