Things I wish I could tell my 18 year old self.

1) Accept you will make mistakes.
2) Truly learn the language you are using.
3) Write idiomatic code for the language you are using.
4) Be upfront about not knowing something.
5) Don't let not knowing something stop you from learning it.
6) None of us knew X until we learned it.
7) Understand your strengths and weaknesses as a developer, play to them.
8) Be willing to try new things.
9) X language isn't ALWAYS the best choice, X paradigm isn't ALWAYS the best choice. Choose wisely.
10) You won't know everything, but you might know more than others.
11) Your ideas and ego don't matter more than ensuring the product works.
12) "Perfection is the enemy of the good [enough]" - Voltaire
13) "Perfection is not achieved when there's nothing more to add, but when there's nothing more to remove." - Einstein.
14) Conflicts happen, deal with it.
15) Develop a toolset and really learn them.
16) Try new tools, they may prove better than what you were using.
17) Don't manage your own memory unless you absolutely have to, you are probably not smarter than the collective intelligence of the team that built the various garbage collection methods.
18) People can be dicks, especially online.
19) If you are new and people are being dicks to you, did you skip past the irc message about etiquette? If you did, you're the dick in this situation.
20) It can be tough, but it is fun, so have fun!

Imagine yourself exploring Medium, looking for some new awesome tools to try out.

You accidentally find the new, promising programming language. It called Blow. It promises itself to be “idiomatic”, “minimalistic”, “simple” and “handsome”. And it also compiles to Electron. You decide to give it a try.

It has its own package manager, simple and idiomatic – every package is “blow add” away. But it’s only three packages available: the “blowsay”, just like “cowsay”, the “this”, printing The Blow Manifesto and “blue”, which is simplistic, simple and minimalistic idiomatic handsome functional frontend framework built with simplicity in mind.

You want to build a todo app, so you type “blow add blue” and press enter.

Following Medium articles written by some guy wearing Ray-Bans, you managed to finally put a todo app together, after seven hours of straight up coding and fighting that simple and idiomatic syntax, trying to make it do what you need. Alright, it’s time to build it.

It has built-in task runner named “job”.

So you type “blow job todo”.

You spending three hours more doing “blow job this”, “blow job that”, trying to blow job everything you see. You’re tired and mad at those damn blow job hipsters created that. You literally suck at programming in that.

Everything falls apart. Things doesn’t work. And after another “ENOENT 0() 0x628 NOT_SUPPORTED”, you give up, admitting that you’ve really sucked at this.

Just before you, my fellow system programmer, scroll past this, let me say this:

🍬 The web is actiually simple. 🍬

Both HTML and CSS is declarative. It's all easy when you understand the concepts, learn how to be idiomatic and quit trying to do that imperative bullshit in languages that aren't imperative.

HTML is simple. You know the boilerplate: doctype, head, body, that's all. Just mark it up and do NOT look at it before you end, mark it up as it were article or something. The appearance is up to css.

CSS is simple. You may even forget bem or rscss, you're already a skilled software developer. Use common sense and your code-splitting and naming skills you gained reading The Code Complete or doing software development for years.

Forget mockups. Forget absolute positioning, forget setting width and height in pixels. Go to awwwards, find some inspiration. Draw some buttons and fields on paper with your good old pencil. Then go and write some css. Feel free to steal some shadows and transitions from codepen.

Read about 8-pixel grid system. Let every element push away from others by setting something like margin: 16px; and whoops! You've just got fully responsive and got great vertical rhythm without even using media queries!

Oh my god, do NEVER set width and height explicitly! Type something like button { width: 120px; } and bang! The entire web page is broken. Quit that shit. Let it resize as it should. It will resize itself to fit its contents.

HTML is by default ready for your template engine. That's how you receive data from server — as server-side rendered, plain old HTML page. On the other hand, the form element is the most axiomatic and simple way to send the data to server. That's how you send it — as plain old GET or POST that every webserver can handle.

All of there are true:
1. It's easy to get great 100% responsiveness without media queries.
2. It's easy to align items in row, it's just one line of css. Maybe two, if you still want elements to wrap, but want to use flexbox:
.parent {
display: flex;
flex-wrap: wrap;
}
3. HTML and CSS are fast by default.
4. You don't need mockups to achieve great visual experience. Mockups is imperative, web is declarative.
5. You may not even need JavaScript to make great website.

Go on, ask me a question about web! I'll ready to answer everything.

Not having finished any education, and writing code during interviews.

I have a pretty nice resume with good references, and I think I'm a reasonably good & experienced dev.

But I'm absolutely unable to write code on paper, and really wonder how some devs can just write out algorithms using a pen and reason about it, without trying/failing/playing/fixing in an IDE.

Education I think.

I can transform the theory on a complex Wikipedia page about math/algorithm into code, I can translate a Haskell library into idiomatic python... but what I haven't done is write out sorting functions or fibonacci generators a million times during Java class.

I don't see the point either... but I still feel utterly worthless during an interview if they ask "So you haven't even finished highschool? Can you at least solve this prime number problem using a marker on this whiteboard? Could you explain in words which sorting algorithm is faster and why?"

"Uh... let me fetch a laptop with an IDE, stackoverflow and Wikipedia?"

I am sure this has happened to all of us in some extent with some variations.

Colleague not writing comments on code.
Ask him something like "How am I suppose understand that piece of garbage you have written when there is no comments or documentation?"
This keeps happening for a long time. Some time after, I write a kernel module using idiomatic C and ASM blocks for optimizations (for some RTOS) and purposely not write neither documentation nor comments.
When he asked for an explanation, I answered to everything he questioned as general as I could for "that trivial piece of code".
After that he always documents his code!
Win! 🏆

Well this is the thing. I have been starting to replace a lot of my shit with Golang. I think it is a great language because of one small fact: it is a boring language.

With this I don't mean that it is not incredibly fun to use. It is and honestly I feel that a lot of the concepts that I had from C passed quite nicely with some additions. The language does not do anything special and there is no elegant code. It works in a very procedural fashion without taking into consideration any of the snazzy things found in JS, Python, c# etc etc. Interfaces and struct make sense to me, way more than oop does in other languages. I don't need generics with the use of interface parameters and I have hadly found a situation in which I have to strive too far away from the way things are done with Go to be happy with it, then again my projects are not hard or by any means groundbreaking (most of them deal with logistics or content management and a couple of financial apps that I am rewriting in Go from work)

The outcome is fast and easy to read since idiomatic go is for the most part very readable(no people...single letter variable names are by no means a standard and they should feel ashamed from it)

I miss the idea of a framework, but not so much and the docs and internal code for Go is just way top inviting. I believe the code to be readable enough than anyone that has gotten used to the syntax and ideas of the language can just jump in and start learning. This is the first language that I have learnt from studying the code as it is inside of the standard lib, the same I cannot say for any other language or framework.

Also, it play beautifully nice with vs code.

I dunno man, I feel that I am doing something wrong. I have projects built in Node, php, python, ruby and spring java as well as .net core and I still find Golang way more appealing simply because it goes harder than Python with "one preferred way" to do things.

The lang does not make me feel like a pro, i certainly develop in it at pro speeds, but it was made with beginners in mind to built fast and concurrent apps, with the most minimal syntax possible.

I guess my gripe with it is that it gets shunned from this, saying that it ignored years of lang research to make it as dumbed down as possible. Which it did, lack of generics amongst other things certainly make it seem like, but I will not say that it was poorly designed. Not at all, I believe it is a testament of amazing engineering. To be able to create such a simple yet amazingly powerful language.

Wish there were more to it. Wish there was a nice gui lib or a ml framework comparable to the ones offered by python and java. But I guess such things will come with time.

I feel stupid with this language.

And that is fine.

Today, I found this in our upstream repo. How the fuck does it even get merged?
No use of tempfile, instead of idiomatic it's idiotic. I have changed that system, now I am hoping i don't have to refactor thia shit.

Can we take a moment to recognize how absolutely retarded JS' event system is?
Events aren't objects. No, they're managed by an object, and identified by a string.
To subscribe to an event, you call object.addEventListener(name, callback). Because for some reason we can't just have an event object. Events MUST have an owner.
But to unsubscribe you don't call the function addEventListener returned, you don't use the token it returned either. No, you pass the same function to removeEventListener.
Because we don't use serializable tokens like in PP, and we don't return functions like in FP, no, we use functions as tokens, realising idiomatic DFP.

There is a fine line between idiomatic code and idiotic fucktard.

Don't use "best practices" as an excuse to write shitfuck code.

> As a developer in the Go world, I would recommend you to embrace idiomatic Go patterns and avoid dependency injection.

google literally created a DI lib for go.

Rust noob Q:

Given x a variable on the heap, e.g.

let x = String::from("Hello, devRant!");

Then, given some function that I didn't write (from a library) that takes ownership of its argument:

fn some_function(y: String) -> bool { ... }

How would you handle this situation:

if some_function(x) {
another_function(x); // not ok, because x has gone out of scope in the line before
}

Is it idiomatic to just clone() x in the first call? That seems bad practice, because it's the second (or some other additional) call that needs x. What should I be doing instead?

In most businesses, self-proclaimed full-stack teams are usually more back-end leaning as historically the need to use JS more extensively has imposed itself on back-end-only teams (that used to handle some basic HTML/CSS/JS/bootstrap on the side). This is something I witnessed over the years in 4 projects.

Back-end developers looking for a good JS framework will inevitably land on the triad of Vue, React and Angular, elegant solutions for SPA's. These frameworks are way more permissive than traditional back-end MVC frameworks (Dotnet core, Symfony, Spring boot), meaning it is easy to get something that looks like it's working even when it is not "right" (=idiomatic, unit-testable, maintainable).

They then use components as if they were simple HTML elements injecting the initial state via attributes (props), skip event handling and immediately add state store libraries (Vuex, Redux). They aren't aware that updating a single prop in an object with 1000 keys passed as prop will be nefarious for rendering performance. They also read something about SSR and immediately add Next.js or Nuxt.js, a custom Node express.js proxy and npm install a ton of "ecosystem" modules like webpack loaders that will become abandonware in a year.

After 6 months you get: 3 basic forms with a few fields, regressions, 2MB of JS, missing basic a11y, unmaintainable translation files & business logic scattered across components, an "outdated" stack that logs 20 deprecation notices on npm install, a component library that is hard to unit-test, validate and update, completely vendor-& version locked in and hundreds of thousands of wasted dollars.

I empathize with the back-end devs: JS frameworks should not brand themselves as "simple" or "one-size-fits-all" solutions. They should not treat their audience as if it were fully aware and able to use concepts of composition, immutability, and custom "hooks" paired with the quirks of JS, and especially WHEN they are a good fit.

!rant

Software development has acquired some interesting jargon over the years, but I keep wondering if other languages and cultures have commonplace expressions for what can be translated as "improvisation-oriented programming" or "hammering code" (i. e. hacking something in a brutish way)

I don't get it, why having more than one decorator looks "weird"? that's idiomatic Python AFAIK, that's sounds more like nitpicking on aesthetics :/