this is anecdotal of course, but as someone who has never written a line of production Go code (but can tell at a visual glance this is in fact, Go), small functions (green) made sense to me as soon as I started reading it. The single function code (red) became hard to follow at some point. It felt like the function was doing 10 different things with a lot of branching and no particular single purpose. Maybe it's the Python background in me, but I am not seeing how the single function is better to read than small, self-contained functions.

It's not a Go thing. I've inherited a number of large linear functions of the author's favored style in several C-syntax family languages, they all become increasingly incomprehensible as they grow longer and older. For any advocate of that style, the only way to maintain them (and retain their supposed clarity) is to extract functions and then re-inline those functions after a comprehensive refactoring. Otherwise, they accrue so much cruft over time that their legibility is completely lost.

Your only other option is to freeze them and never make changes, that doesn't happen much in real-world code (though it probably should).

Literally extracting the functions and then re-inlining them makes no sense. Having that as a sort of mental model while you're working on the code does make sense.

It’s to enable refactoring when it grows large. Most effective way I have found for 1k SLOC or larger functions. I usually don’t re-inline because the result after refactoring is almost always clearer.

Trying to in-place refactor those things is an exercise in frustration. That’s part of why they grow so large, from observing their proponents in action. They don’t actually know what the functions do, only where to add a new path and repeat themselves.

Hi! is the Cloud Software Engineer role only for Remote in France? do you have any other roles open?

links in the blog are 404ing

requests, the python package for HTTP/S

One of the most dumbfounding things I've encountered throughout my career is the python community's dogged persistence at avoiding using libcurl.

Getting a resource in requests:

    import requests
    body = requests.get('http://pycurl.io/')

Getting a resource with libcurl:

    import pycurl
    from io import BytesIO
    
    buffer = BytesIO()
    c = pycurl.Curl()
    c.setopt(c.URL, 'http://pycurl.io/')
    c.setopt(c.WRITEDATA, buffer)
    c.perform()
    c.close()
    
    body = buffer.getvalue()

Doesn't answer the question why nobody has build an interface like the first example over the low-level libcurl bindings, or if someone has done so, why it hasn't been more popular.

I'd guess: because distributing packages with native dependencies is sort of a a pain, and was way worse in the past, especially cross-platform, and thus python-only packages are preferred. Leaves open why libcurl bindings weren't choosen for stdlib.

Since we're on the topic of code quality, this example is an incredibly strong indication that you should be using an interface.

And while the requests library might be shorter/easier, it doesn't offer nearly the guarantees that it will exhibit the expected behavior nor the feature flexibility that libcurl does.

https://curl.haxx.se/libcurl/features.html

https://curl.haxx.se/libcurl/theysay.html

What are the advantages of using libcurl over whatever requests does?

There is a very short list of projects that have had more engineering effort put into them than libcurl. Single digits. It's incredibly robust and battle-tested. Just about everything you could want to do with it performs as expected and is well-supported. On top of that, its performance is very good.

We're literally in the business of building on the work of others. Avoiding libcurl seems like an incredibly naive choice to me.

not sure if you live/work in the United States, but the majority of those questions are illegal to ask.

I am sure you've heard all of these but they worked for me: 1 month of doing this on the regular and I've never been more productive.

All you need is 40 hours a week of solid productive work. that's it. Get that in your head and work from this first principle.

make time for downtime - allow your mind to wonder and be bored and go off tangents sometimes. Counterintuitively, that's part of the magic. do some breathing exercises throughout the day(if you hate meditation like me lol)

Get a gym membership and do a rigorous workout 3/4 days a week.

Become friends with water: seltzer, regular, fruit-infused, tea, it doesn't matter. drink lots of it. It'll have 2 main effects: keeps you hydrated of course(with the many benefits) and it makes you get up every few hours to go on a break.

Typora

Want to correct that the U.S Web Design System was built by a USDS sister org, 18F under the GSA/Technology Transformation Services https://www.gsa.gov/about-us/organization/federal-acquisitio...