If you were never exposed to functional programming before, learning Haskell will give you a whole new perspective on how you write code, and I bet it will make you a better programmer just because of that.

With that said, in Europe I ever came across exactly zero job ads that require Haskell, and exactly one in Singapore. In North America / Bay Area it might be more common though.

Typetalk.

It also has a free tier up to 10 users, that retains the most recent 10k messages.

It seems the only jobs listed here are from Bytedance

I write a lot of documentation. I do it not because others ask, but because I genuinely believe it is going to be helpful to someone at some point, and anticipate this need. So when Bobby from marketing asks about a feature, or Kate the junior dev can’t wrap her head about some algorithm, hey, I got them covered!

So I think this mindset is the first thing you need in order to get going. It will inspire you to write more and better.

Secondly, my practical advice is the following: divide your doc in sections. Plan them out beforehand by writing just titles and subtitles. See how they fit together, if their sequence makes sense. Rearrange them until they convey a clear story. Usually you might want to have three macro-sections: 1. Introduction - what is the document about, who is it indended for, and why it was developed. This helps set expectations right off the bat. You can also describe the big-picture goals of the system/feature. What is it used for. What are the main use cases. 2. System/Feature Overview: here you can describe the big-boxes architecture, the main components (apps, servers, middleware, db, whatever), what they do, and how they work together. Describe communication protocols and standards followed. Describe functionalities the system provides. You can follow up on the use cases you mentioned in part 1 and show how the system delivers them. 3. Technical Details/Implementation Choices: depending on the audience of your doc, you might want to document non-obvious design choices. This is also where might want to describe expected inputs and outputs. If it’s an API, describe the routes, accepted methods, paylods. Provide actual examples, as many as you can. Describe the data model.

Then as you follow this trace, you might find out you wrote a lot about a certain topic. Depending on the level of detail you want to achieve, break it down in smaller sub-sections, or move parts over to section 3.

As for the writing style, you might want a prose with short sentences and easy language. Make sure to explain stuff thoroughly and not take anything for granted. Everything that looks damn obvious today, won’t be 6 months from now.

Sorry if this looks like a stream-of-consciousness. It sort of is. I hope you can find some of it useful.

It's a rather structured stream-of-consciousness, thanks. I'm mainly afraid that because I really don't know what are the parts of our system and what they actually do that I'll screw this up. But I really trust my support system of senior devs and PMs and with my beginner mind this could be a great learning experience.

Personally, I would still choose gin. Gin seems to be more straight to the point. To name one, compare goyave router.Route("PUT|PATCH", ...) with gin router.PUT() or router.PATCH(). Also I'm not a fan of adding a lot of functionality and opinionated behavior into web frameworks. e.g. configuration files that need to be in a specific place in my workdir, "automatic 404 when a database record is not found", etc.

But sure, if you want to get a server up and running from scratch very quickly for a POC or a simple API-over-a-database app, this lib might be a good starting point.

Fair point. The "automatic 404 when a database record is not found" is purely optional and something you choose to use or not, like all the other helpers. For example, see below code:

  func Show(response *goyave.Response, request *goyave.Request) {
    product := model.Product{}
    id, _ := strconv.ParseUint(request.Params["id"], 10, 64)
    result := database.GetConnection().First(&product, id)
    if response.HandleDatabaseError(result) {
      response.JSON(http.StatusOK, product)
    }
  }

"response.HandleDatabaseError" is the helper we're talking about.

Doesn't Gin still have big issues where it's not compatible with native net/http middleware?

Much of these hiring practices are just a self-perpetuating narrative. Just spreading the news that interviews at your company are hard is a way to discourage unqualified candidates. And candidates that don't want to put up with your (perceived) bullshit. Either way, the choice of playing the game is entirely on us.

what stops these people from downloading mine or anyone's resume off LinkedIn and use that for their purposes? they wouldn't even need to bother contacting me first

Nothing. And they do already convert your PDFs to Doc for editing, often destroying part of your layout. At one job interview for a frontend developer position, I was very embarrassed to learn that the idiot recruiter had done that to my CV. My interviewer jokingly showed me how my CV looked all messed up - wrong alignment, missing icons, mixed up fonts, weird borders. All this because the recruiter wanted to remove my email address from the document...

Well, one could print the PDF on paper and then scan it as image, it will probably loose some resolution/detail, the layout will stay, unless the recruiter uses OCR, and then you will have, besides a messed layout also several typos ...

As the first stage of the interview, we give a take-home test with no constraints. We just ask them to put together some code that works with one of our public APIs.

I think this is decently respectful of the candidate's time, while giving us the opportunity to review some actual code written by them. And yet, most of them don't even bother... Well, I get that you are busy, but I don't feel comfortable investing time in an on-site interview without seeing any code first.

Disclaimer: If they provide a link to their github with some solid projects or OSS contributions, we skip the take-home altogether.

> Conferences don't exist to convey information

I don't entirely agree with this. Many speakers talk about their experience with some technology or problem. If it's not presented as a sales pitch - which sometimes might happen -, it is definitely valuable to hear about real-world use cases. And then you even get to ask them questions at the end. It is an opportunity to share info and practices that you can hardly get in the same way from a non-interactive blog article or a forum thread.

> When people attend conferences, they're doing it to be seen

This might be true, and as you say, it's all business. I don't think this is necessarily bad (I'm not saying that you think so). Conferences are useful to meet people in person and expand your network, which is also very valuable. Maybe some do this as a deliberate calculation, some others are genuinely interested in socializing. That's all very fine. And ultimately if speaking at a conference has chances to improve my resume, why would I not go for it? It's all business, right?

> If you're at a talk that's truly unbearable, just tune out or walk out if it's that bad.

This is good advice. Overall I would say conferences are a decent tool for staying in touch with the community. Not all of them are bad, and not all speakers have inflated egos.

Me and my team have been using Backlog for quite a while now and it's truly refreshing https://nulab.com/products/backlog/