螺丝录

[aeonu]

我们是会等来疫情后时代还是会进入后疫情时代？

[aeonu]

三生蜉蝣，浮游三世

蜉蝣者，百世之一瞬，天地之些微也！  战战兢兢起于池塘之泥缝，瑟瑟缩缩攀于洼凼之衰草。晨露朝霞，裹腹其身；浊泥腐草，染污其背。嗟乎跌跌撞撞，避于虫蝇之口腹蜜贱；叹乎摇摇摆摆，惊于水风之浩浩荡荡。蝉鸣蛙唳，露浓羽生，纤纤然也柔弱。然则朝生夕朽，逐世而转，转之不得，三生蜉蝣，浮游三世也！

哀芸芸众生，营营汲汲，其浮生未竟，轮蹄征逐；叹甲乙丙丁，虫蚁阡陌，其浮游雾云，雨露袭奔。蜉蝣万千，三生三世，朝欢夜殁，气色衰荣，有不同乎？

一世浮游，大观红楼，梦花赏月，鱼游蝶穿于烟花巷柳，朝悲暮欢，酒深缘浅。惜乎细腰初心，放浪形骸，情不定而心意广，仇不叠而恨露消。叹乎情飞意摇，色心色行，快意而不觉山江之仇恩也！  两世浮游，戈壁滩涂，黄沙蔽日，烟舞尘飞于落日长河。日炙夜寒，风嚎虫嘶，痛不止而趾复裂，情义尽而泪旧痕。行行役役，癫癫疯疯，看山是水，看水是山。营营且且，苟且偷生，不知日月之晦明，渐知人心之浊恶。呜呼哀哉！羽轻展兮而鼠瞠目，冠微正兮而虫挠心也！  三世浮游，天清云淡，莲荷素白，泪烛轻滴于耶路撒冷，雾香袅袅于布达拉宫。噫，浮游圣境，其身心难初，情义已遥。涉千山万水，饮苍海之水而不咸，亦不淡！逢路人是非而不动，亦不觉。心动而身随，意渴而津生，酸甜咸宜也！

蜉蝣百世，出水洼之一隅而浮游于蜉蝣之境，跃阴寒之窨井而淡然于井内之争。风习习而意靡靡，光忽忽而情非非。浮游天地，展华羽而不艳，着丽冠而不骄。离子之上，月华之外，天地之于我，亦蜉蝣也！

[aeonu]

储能对囤菜，一个道理！

储能的风口没到，囤菜的风口先来了！

一些食材保存方式

1.罐头 2.泡菜 3.咸菜 4.皮蛋 5.冷冻冷藏 6.腊肉（腌制品）

[aeonu]

上级对下级：既怕你乱串乱来，又怕躺平你不来！

[aeonu]

口罩3年

菜囤北上广深， 人走彝蒙羌藏。

[aeonu]

无计划，搞变通（比如，说是树竹清障，实际却是去处理台区缺陷），东说西做，指东打西。

[aeonu]

宣传的导向：

嫌贫爱富 拈轻怕重

[aeonu]

总量控制定律：

繁华过后就是清冷

聪明隔壁就是愚蠢

欢乐后面送来忧伤

鹤立鸡群嬉笑荒唐

[aeonu]

牲口系交流方式是直流 非牲口（宠物系）交流方式是交流

[aeonu]

与其亡羊补牢，不如曲突徙薪！

[aeonu]

用PH值来定义批话多的讲话

PH=7.0，属于中性，不多也不少

PH《 7.0，则是酸性，批话多！

PH 》 7.0 则是碱性，话少。（碱通俭，俭，少矣）

[aeonu]

才疏人2

[aeonu]

仪式感，形式感，其实质是刷存在感！

[aeonu]

前边是车祸，后边是人祸，中间是一群蠢货！

[aeonu]

关键不在于导向，而在于倒向！

宣传，绩效即如是！

[aeonu]

电老虎app，实现涉电人身死亡事故的历史记忆。

会疯app，实现所有会议的历史记忆。

全部都用单线图的方式予以记录和呈现。

后期应该加入区块链防篡改功能。

[aeonu]

自我加压还是自我加戏！

[aeonu]

芣苢 佚名 〔先秦〕

采采芣苢，薄言采之。采采芣苢，薄言有之。 采采芣苢，薄言掇之。采采芣苢，薄言捋之。 采采芣苢，薄言袺之。采采芣苢，薄言襭之。

[aeonu]

财疏情薄-风华正茂！

[aeonu]

上怼天，下怼地，中间怼空气！

[aeonu]

七律·梨花开满鹧鸪山

飞雪一路去红颜，碧水白山天地间。

日落黄龙七彩烨，月出九寨五花闲。

龙吟巴郎雾难去，凤哕夹金彩云还。

大小金川流不尽，梨花开满鹧鸪山。

[aeonu]

大炮，飞雪，奇葩！

[aeonu]

你没有工作，没有任务，得写明为什么没有。好玩！好耍！

[aeonu]

瑕不掩瑜！笑话！

[aeonu]

根据国家能源局《关于2019年风电、光伏发电项目建设有关事项的通知》（国能发新能〔2019〕49号） ，光伏6MW及以上为集中式，6MW以下为分布式。

根据四川省分布式光伏建设管理相关政策，单个项目在2MW以下的由市（州）电网企业出具消纳意见，2MW及以上的由省级电网企业出具消纳意见。

[aeonu]

STATE POWER INVESTMENT CORPORATION LIMITED

[aeonu]

这个单位有烟火气！

[aeonu]

一个二杆子，一个250，合起来就是2250，好耍！

[aeonu]

成府，成腐！

[aeonu]

越是喜欢说话的人，越是心机深重。

[aeonu]

当一个人渐渐变得沉默 不轻易对别人承诺 脸上平静如水 遇事不慌，处事不惊 动作有条不紊，说话字斟句酌 不在意别人的评价 专注自己的内心 这个人就成熟了 年少的轻狂张扬可以犯错，因为年轻允许试错，人这一辈子，其实就是在无数个错误与挫折中度过，经历过一些事，交往过一些人，我们才懂得什么是人生。很多人为生活，违心的活成了别人想要的样子，当年岁渐长，岁月苍桑，我们开始审视内心，看多了风花雪月，品尝过人间百态，对别人恭恭敬敬，对领导言听计从，对得起所有人，却唯独对不起自已。 时光慢慢变老，内心不再浮躁，云卷云舒去留随意，花开花谢季节更替，内心归于宁静，从此宠辱不惊。

[aeonu]

这个世上， 最愚蠢的行为， 就是不停的跟别人讲道理， 要知道，不是所有的鱼， 都会生活在同一片海里， 人各有不同， 无论遇到什么样的人， 都不稀奇， 不是所有的人， 都值得我们关注， 不是所有的事， 都值得我们劳神， 有些人争不来，有些事不必争， 位置不同，少言为贵， 认知不同，不必争辩， 三观不合，浪费口舌！ 永远不要和不同层次的人争辩， 因为每个人都只能 在自己的认知基础上思考问题

[aeonu]

小人的特征

1、目光短浅，只看眼前利益，看不到长远。

2、对上谄媚，对下欺压，不会真诚待人。

3、人前一套，背后一套，做不到表里如一。

4、嫉贤妒能，打压异己，本事没有，内斗很强。

5、偷奸耍滑，不够诚实，万事逃避，没有责任心。

6、见风使舵，人云亦云，没有主见。

7、缺乏德行，没有基本的道德标准。

8、善作假，两面派，人前一套，背后一套。

9、无事生非，唯恐天下不乱。

10、只顾个人利益，为了个人利益不惜损害他人正当权益。

11、落井下石，在他人遭遇不幸时，缺乏同情心。

12、栽赃陷害，为了自己的利益可以不择手段。

13、贼眉鼠眼，鼠目寸光，眼神游离不定。

14、说一套，做一套，说的好听，做的难看。

15、墙头草，顺风倒，永远跟着利益。

[aeonu]

大事不流水

[aeonu]

作威作福，妒贤忌能，刁钻刻薄！苛刻如海！权势笼络！格局担当！

[aeonu]

稻盛和夫说： 人性最大的丑陋不是自私， 也不是贪婪， 不是虚伪， 也不是狂妄。 而是为难他人。

[aeonu]

你以为飞来了一只天鹅，结果一讲话，嘴一松，掉了一只癞疙宝下来，井底之癞疙宝。

[aeonu]

任正非：要警惕不会做事却会处世的人受到重用。 其实每个公司和单位都有这样的人，做事不行，但就是善于做人情，对人情世故很精通，这样的人基本都是组织的负资产。 因为他们贡献不了价值，所以才更要经营“关系”，他们更会看别人的脸色，更喜欢揣摩别人，投其所好。 这样的人也许做不到绝对没有，但最好要少一些才好。

[aeonu]

横梁：两边各余38厘米，共76厘米。立柱总距离3240厘米。副梁两边各余15厘米，剩余长度3700厘米，间隔40厘米，共需9根边梁。

[aeonu]

能当上领导，要么能力极强，令人确实佩服，要么腹黑，让下属迫于淫威，敢怒而不敢言，一般是，第二种比较多。

[aeonu]

5年计划：

1.c，go，python，app熟练掌握，开发应用，进入商业应用。

2.gs稳定盈利。

3.专业低压配网。

[aeonu]

若诗若画若尔盖 花海花湖花无缺 花海花湖花无语 花海花湖花来约 花海花湖花迷茫 花海花湖花迷惘 花海花湖花迷香 花海花湖花迷离

非雾非花非浮云 非雾非花非吾心 非雾非花非烟云 非雾非花非云烟

观雾观花观云烟

若诗若画若尔盖 观鸟观花观云烟 观鸟观花观云白

观水观花观人烟

观鸟观花观人间

观水观花观人烟

观鸟观花观云闲

观鸟观花观云天

观鸟观花观尘烟

[aeonu]

内径宽度：260cm

板材宽度：4.5cm

外经宽度：269cm

[aeonu]

岷水抢沫（水）

德绵夺阿（位）

[aeonu]

人闲龙泉驿， 花开三圣乡。 花迷三圣乡。

[aeonu]

没有真正宜居的城市，因为人类舒适区域是：温度22—24℃，湿度：45～65，海拔低于1000米。全世界根本找不到。因为地球围绕太阳转，而且地球是倾斜自转，阳光点，大气运动总在改变，所以每个点都是在变化的。所以，要想宜居就需要人运动：10月份去海南三亚，次年3月末去厦门，4月末去威海，6月份去哈尔滨待到10月份再去海南三亚。

[aeonu]

本来无一物， 何处惹尘埃！

[aeonu]

编程语言和它们的岁数： C → 50岁 C++ → 37岁 Python → 31岁 COBOL → 63岁 JavaScript → 26岁 PHP → 27岁 Java → 26岁 C# → 22岁 Go → 12岁 Ruby → 27岁 Rust → 11岁 TypeScript → 9岁 Perl → 34岁 CoffeeScript → 12岁 SQL → 48岁 Crystal → 7岁 Dart → 10岁 Scala → 18岁 Kotlin → 10岁 Curl → 24岁 R → 28岁 Carbon → 0岁

[aeonu]

道：闲钱，耐心，信心！

[aeonu]

蛴螬 金龟子幼虫

[aeonu]

Professional Programming: The First 10 Years 17 May 2022

Last month, April 2022, marked the 10 year anniversary of my start as a professional programmer.

I started programming earlier than that, but hadn’t been paid a salary. As a teenager I built websites and IRC bots and wrote tiny Python scripts. Then I stopped and played guitar for a few years. In my twenties, I rather coincidentally rediscovered how much I enjoy programming when I was asked to build another website and found out how much had changed about the web while I was away (it’s HTML5 now!).

That made me wonder whether programming wouldn’t be the better career choice than continuing to study philosophy at university. Robin answered that question for me by generously offering me a paid internship.

Now it’s been 10 years, which is, to be honest, neither a significant marker of my growth as a programmer nor my career, but realising that it’s been 10 years made me pause and reflect.

The following is a loose, unordered collection of thoughts that come up when I look back on the past 10 years. Things I’ve learned, things I’ve unlearned, things I’ve changed my opinion on, things I never thought I’d believe in and now do.

They’re very much products of the context in which I helped develop software: as an intern for Robin, then as a junior developer for Robin, as a software developer for a small German startup, as a senior software developer for a German startup inside a huge German corporation, and now as a staff engineer for a fully remote, asynchronous US startup. Take that as a disclaimer. I bet if I’d worked in a game studio, a hardware company, and a big tech corporation instead, this text would be very different.

Fearlessness is undervalued

Most of the programmers I look up to and learned from share one trait that is rarely talked about: fearlessness.

They dive into an unknown codebase without fear. They open up the code of a dependency that they suspect is misbehaving without fear. They start working on something without knowing how they’ll finish.

It’s inspiring seeing someone being fearless, but becoming fearless yourself is one of the best learning accelerators I’ve found.

You can’t predict the future; try and you might end up in trouble

We all know this. Of course, we can’t predict the future.

But it took me years to truly take it into account when programming.

In the first third of my career I’d think: we will need this, so let’s build it now.

In the second third: we might need this, so let’s prepare for it.

Now: we don’t know whether we’ll need this, it’s a possibility, sure, and it looks like we might need it, yes, but things change all the time, so let’s build what we know we need right now.

Of course I write code so it’s easy to test

I also write code so it’s easy to read and understand, or easy to delete, or easy to modify, or easy to review. I don’t write code only for the computer to execute.

Nothing really matters, except bringing value to the customer

Type safety, 100% test coverage, the ability to fluently express business logic in code, perfect development tooling, an efficient system that wastes no resources, using the best programming language for the job, an elegant API design, a fast feedback loop, writing great code – these are not the goal.

Here’s the goal: providing value to your customers, by shipping software that solves their problem, repeatedly.

The things above help you do that – faster, cheaper, more efficiently, safer, with greater joy – but they’re not the goal. The goal is to provide value to your customers.

The trap: it’s often easier to write software than to deliver it. But delivering is what it’s all about.

Perfection is unachievable

I’m not sure I ever thought it is, but now I’m certain it is not. Everything is the result of trade-offs.

You will never reach 100% on every axis that you care about. Something has to give. And when you think you did make it perfect, you’ll soon realise that you forgot something.

My aesthetics have changed too. Instead of looking for the beauty that lies in perfection I now think the program that succeeds despite its flaws is beautiful. Look at that little program go, holding the internet together, despite the 17 TODOs in it.

If you can’t connect it to the business, it doesn’t matter

You can refactor a codebase and clean it up significantly, making it easier to understand for everybody and easier to extend, but all of that won’t matter if that codebase gets deleted four months later because the project didn’t help the business.

You can spend weeks adding tracing and observability to all of the code you write, only to realise that nobody will ever look at it, because that code runs three times a day and never causes any problems.

You can tweak and optimize your code to run so efficiently that the company can halve the number of machines required to run it and then see that the costs you saved are nothing in comparison to the salary you were paid while optimizing.

You can spend your time doing fantastic technical work and still waste it.

Figure out what the rule is trying to prevent, then consider the rule optional

If you’d asked me 5 years ago whether TDD, Clean Code, Software Craftsmanship, and other schools of thought are dogmatic, I would’ve said “no! Can’t you see? Clean and good code is important!”

Now I look back at the time when I thought that a rule such as “a method should not be longer than 5 lines” was useful and shake my head.

It’s not about the rules! It’s about the problems these rules are trying to prevent. If you don’t have the problem they’re trying to prevent, or you can prevent it another way, you don’t need the rule.

Write tests that give you confidence that the system works as it should

Don’t worry too much about whether a test is an integration or an end-to-end test, a unit test or a functional test. Don’t fight with others about whether you should test private methods or not. Stop worrying about whether you should hit the database in tests or not.

Instead write tests that tell you the system is working the way it should. Ideally with 3 keystrokes and in less than 1 second.

This one took me a long time, a lot of ultimately useless discussions, and bugs in my code to learn.

Best practices are often based on the assumption that you know what the code should do

If you know exactly what you want to build then best practices and patterns can help you, by giving advice on how to build it.

But if you don’t know yet what the program should do, or what it will look like in four weeks, then some best practices can make things even harder.

Some practices are the best when applied to a rewrite, but the worst when you’re still exploring.

Using other people’s code is not as good as I thought

I started my career writing Ruby and JavaScript, with package managers being available and the question “isn’t there a package that does that?” always hanging in the air.

Common sense dictated: if you can, try to use a library instead of writing it yourself. Reuse code as much as you can. Don’t reinvent the wheel. Don’t copy & paste. That was what I believed for years.

But there are downsides to that. Sometimes writing that one function yourself might actually be better than adding a dependency.

Dependencies aren’t free. You have to keep them up to date. They increase your compile or loading times. They add strange things to your stack traces. And very often they do more than what you need them to do, which means you’re paying for more than you’re getting.

When you’re glueing other people’s code together, there’s a very real danger that the glue is where complexity will accumulate. But glue code is the last place where you want your complexity to live. It hides complexity. What you want is to make complexity as visible as you can, shining a light on it with the hope that it turns into dust and disappears.

Sometimes it’s better to write it yourself than to use other people’s code.

Some companies get it, others don’t. But nobody’s perfect

There is a big difference between developing software for a software company and developing software for a company that employs software developers because it has to. It’s a joy to work for a company in which leadership gets software and how it’s made.

That being said: I don’t think any company has it all figured out. Everybody’s winging it to some degree.

Investing in feedback loops is never wasted effort

I’ve never regretted improving a feedback loop. Faster tests, better test output, faster deploys, turning a manual feedback loop into something that gives me a signal with one keybinding.

Watch out, though: once you’ve seen the light of developing software with a really fast and high-signal feedback loop, you’ll long for it forever.

Always leave something unfinished at the end of the day

A failing test, a compiler error, a half-finished sentence – end your day with one of these and the next morning you can sit down and continue where you left off, skipping “hmm, what should I do today…” entirely.

There’s nothing that gets me started as fast as a failing test that needs to pass.

Perfectionism is a trap

Perfectionism is based on a lie. You’ll never get to the point where you’re done and sit and rest and say “ah, now it’s perfect”. There’ll always be something. You know it, I know it. There’s no perfect (see above). Accept it and ship and continue building.

Aim for 80% and consider the other 20% optional. It’s freeing and gives you room to breath. You might end up at 99%, who knows?

Sharpen the axe

I’ve gotten a lot out of investing in my tools: Vim, git, shells, the Unix environment, testing frameworks. I truly enjoy spending a Sunday morning with my Vim configuration.

But it’s possible to overdo it and get stuck in the configuration phase, doing endless tinkering. You have to use your tools to get feedback on how to best configure and use them.

Hiring is hard

I’ve done hundreds of interviews now and the most important insight I’ve gained is that hiring is really, really hard. The verdict on an interview has so many random inputs that it makes everything between a Strong Yes and Strong No wobbly.

Often I wish there was a way to find out whether people have the get-shit-done gene.

The most important trait in developers: rolling up their sleeves because it has to get done

Here’s something that all the people I enjoyed working with have in common: they do the work. They know that some tasks aren’t fun or glamorous or interesting. But someone has to do them, so they do them.

Work on a codebase with other people over a longer period of time

Nothing has helped me get better at software engineering as much as working with a group of other people on the same codebase over multiple years.

You’ll see how decisions play out.

You’ll see what ended up mattering and what didn’t.

You’ll see how extensible your code truly is when your colleague tries to modify it 3 years after you wrote it.

You’ll see whether your prediction of “we have 2 of these now, but I’m sure there’ll be 5 in the future” will come true or not and can take the outcome into account when doing other predictions.

You’ll regret writing some code and you’ll be happy that you wrote some other code. You’ll learn from reflecting on the difference between the two.

You’ll see tooling break down just because something somewhere changed and you had nothing to do with it but you still have to fix it.

You’ll say “I’ve never had to think about this in 3 years” about some pieces of software and cherish them.

You’ll see what parts of the codebase new colleagues struggle to understand and which parts they immediately get productive in.

You’ll see what the code you wrote looks like 4 years later.

Knowing the full stack

There’s few things as motivating to me as hearing “you don’t really need to know how it works…”

Sure, I might not need to, but I wouldn’t do the work I do today if I hadn’t tried to find out how a GC works, or how Unix works, or how multi-threading works, or how a database stores data, or how interpreters and compilers work.

It benefits the work I do, too. I can make better technical decisions by being able to weigh trade-offs more accurately, knowing what goes on under the hood.

Typing can be the bottleneck

I’ve said it before. Don’t let typing be the bottleneck.

Code reviews aren’t waterproof

For the longest time I assumed it’s my fault when a bug made it through one of my code reviews. I missed that! How could I have missed that? It’s so obvious!

Later I found out that it’s not just me: other people miss bugs in code reviews too. In fact, they accept and freely talk about how code reviews aren’t infallible. I was relieved.

It changed how I see code reviews: as something imperfect, something that needs to be combined with other ways to verify the code.

Not every code review is worth the effort

Not every code needs a really thorough review. Sometimes, if the risk is acceptable, it’s fine to drop a quick “LGTM!”. It unblocks your colleagues, keeps momentum and, somehow, builds trust.

Negativity begets negativity

The more you give in to negativity, the more you get. Always much more than you wanted.

It’s viral. It starts with snark, it turns into cynicism, it then morphs into “everything sucks”. Soon after, the question of “why even bother?” starts to attach itself to everything. It ends with people hiding excitement and joy and ideas from you.

Being negative is too easy. At a certain point I realised that pointing at things and saying what’s bad about them and shrugging because, well, didn’t I expect this to be bad (everything’s bad, right?) - that’s easy. Easy to do and easy to mistake for an engineering mindset that can spot deficiencies and worst cases (which it is not).

What’s hard is seeing things for what they could be, what’s beautiful about them. Encouraging ideas even when they’re barely something to talk about. Creating and fostering joy. That’s challenging.

So at some point I decided I had enough and tried to do the challenging thing. So far it’s served me well.

Every dial at 100% all the time doesn’t work

I can’t do everything equally well all the time. I can’t write a book and make progress in my career and be a great father and set PRs in the gym and read two books. It won’t work for more than one or two weeks. It’s not sustainable.

Now I let my interests take turns: when I want to make progress on a specific thing, I focus on that for a while and accept that the other things have to go into maintenance mode.

Code has mass

Code has mass. Every additional line of code you don’t need is ballast. It weighs your codebase down, making it harder to steer and change direction if you need to. The less code you need, the better.

Code has to be read, it has to be tested, it has to be kept compatible, it has to stay secure, it has to keep working. Even if it’s not doing any useful work. It doesn’t hurt having it around, does it? Yes, it does. Delete it and move on. If necessary, restore from version control.

The same is true for tests, which I’ve only learned too late.

Programming as a part of my life

Ever since I started as an intern I spent a considerable amount of time outside of work on programming: reading technical books, writing books, working on sideprojects, writing blog posts, giving talks, traveling to conferences, learning new languages and tools.

That some companies don’t care about your college degree if you can demonstrate that you’re really good at programming was fuel for me for years.

I enjoy spending time on programming outside of work, but not all the time. Some of it feels like work. It takes effort to read some technical books. But some things don’t have to feel good while you’re doing them.

My career would be completely different if I had only programmed and learned about programming at my day job.

Computers are fast

Building web applications made me think that 100ms is fast and that 50ms is really fast. Writing a compiler has taught me that 1ms is an eternity for a modern computer.

I still love programming very much

Some of what I wrote can be interpreted as me having grown cynical over the years. I mean: nothing matters and perfection is unachievable? Come on.

But it’s the opposite. I still care. I care very much. But I care about fewer things and I still love programming very much.

Follow me on twitter: @thorstenball. Or send me an email to me@thorstenball.com. Or check out my books at interpreterbook.com and compilerbook.com.

I also maintain a mailing list, on which I sent out occasional updates about my books or this blog. I won't spam you and you can unsubscribe at any time.

Click here to subscribe: Yes, I want to receive your very rare but also charming and sometimes funny emails!