hamdouni

Reading some comments, like 'this is wrong because your job is to respect hierarchy decisions', reminds me how corporate still are military minded...

Getting things done with Go, effectively since then. That does not mean you can't do it with other languages, just that it works well for my business.

Nice to see another language with different approaches... I will check it as it is always interesting to challenge its knowledge

The Google Spreedsheets version : https://docs.google.com/spreadsheets/d/1m1IWh6Mmli8K20DdH2wb...

It's the game of the mouse and the cat :-D We can change the package color like this :

  package color

  type Color interface {
    void()
  }

  type color struct {
    v string
  }

  func (c color) void() {}
  func (c color) String() string {
    return c.v
  }

  var (
    Red   color = color{"red"}
    Green color = color{"green"}
    Blue  color = color{"blue"}
  )

I do not agree with other comments : I'm happily using Svelte in a very specific webapp with a lot of pages : forms, validation and datagrids with complex search queries. I use zero external UI components : if something missing, I can build it in Svelte quickly. It's simple, predictable and ... just works.

For every type of projects I'm involved, I choose Go as the backend and put maximum of business rules there to help me manage changes. Go standard library is sufficient and robust for many (all) cases I faced : http handlers, templates, concurrency...

If a web frontend is needed, I'll take svelte (not svelte kit) to code independente components that talk to the backend. I'll code there only interface logic (no control, no calculation, etc...)

50-60 hours weeks seems too much, even if it is semi-regularly, to have a side project. If you can "cut" 2-3 hours a week from your job, it helps to make space for some tinkering.

If you can, get up earlier every morning, before everybody wake up in the house. You must be very motivated if you are not a morning guy.

Other solution is to have a fixed schedule, like having a meeting with yourself, with a "not disturb" agreement with your family (very difficult with young kids)

This part makes me smile :

  I am not a tab hoarder, I almost never have more than **15** of them open at the same time.

I did not observe the effects you are describing, on the contrary.

Where can I read more about those affirmations ?

Regulation/taxes has 2 effects : as you said it restrains economic growth but it also maintains a minimum 'social' level.

Totally agree on the observation (tendancy to accumulate shiny new tools) and 100% on the radical solution of choosing fewer and boring tech...

Two things come in mind after reading this:

There is no contradiction between monolith and DOTADIW. The code unit is the function, so each function does one thing and does it well.

I don't get why microservices is the opposite of large code base : having the code splitted in different files or in different repo, changes nothing about the sum of all lines of code, no ?

It's more like Pareto 80/20 than 90/10. Maybe 50/50 as the rest to be done is out of my league.

Half done is what I'll think when coding is finished.

You can avoid this by using :

  if err := DoFoo(); err != nil { ...

The 'err' variable will be local to the 'if' so you can write also :

  if err := DoBar(); err != nil { ...

It is also nice to write it in one line :-)

"... your code is technically correct. But let’s consider its performance."

Drop the "but" and you'll engage even more with your mentee.

It's like saying that considering performance is a natural thing to do after writing a correct code, instead of the opposition that the word 'but' introduces.

Dropping the 'but' is a powerful skill !

Maybe. Or maybe it is not obvious with a small example. Not sure about the anti-pattern, but I'm sure an anti-conventional coder ;-)

Avoid deep nesting by testing error case first and exiting/returning immediately.

Instead of :

  If foo then
    bar
  Else
    baz
  Endif

Now I write:

  If foo then
    bar
    return
  Endif
  baz

Exit early makes the code easier to read and understand

Good job !

Glad to see yet another tools in this overcrowded field. It confirms my choice to never use one and stick to a text editor like neovim : key M-J to open a daily file, type in what ever I want and abuse using search and grep via telescope to navigate.

Flat files are easy to sync and mine follow me since 2013.

TLDR; avoid big consumer market, target small b2b market

What a nice bubble to live in ! Boss thankful to be corrected by subordinate, smart people around you happy to help and retired top level exec driving limos.

In all the article, no reference to the business those abstractions or duplications are made for. I mean the way to decide if it is a "good duplication" is to ask ourself if it is a coincidence that it is the same code: 2 business rules having the same implementation does not mean it is a duplication.

Rich people benefit from poor people too

Yes, way down to the making of the keyboard used to type it. 100% organic ;-)

What ever is the age, nobody wants to work with a rude and dismissive person.

Report it as "non phishing". Hope it helps.

I recommend to stick with Linux if you want to stay a learner. Linux forces you to keep up and adapt. If you choose the confort of an obscure black box that do all for you, then you'll loose this. Is it bad to let go this habit to always learn ? I think so.

I'm sure people would say this cognitive burden is not useful and freeing your mind from it will let you get more valuable knowledge. But tinkering with your computer is an underestimate skill.

If the client doesn't care to double the cost to double the leads, why not double the ads ?

Nice to see improvements in podman startup and how the team achieve it...

Constraints (car env) drive creativity !