3 ms·

Probably controversial, but the current scenario of engineering is over engineered. Hacker News is Unicorn-biased, most of the information here isn't practical

Probably controversial, but the current scenario of engineering is over engineered. Hacker News is Unicorn-biased, most of the information here isn't practical if you're just trying to solve problems that take your project from point A to point B. Look into problems, you'll find solutions. Look into solutions, you'll find problems.

hamolton 6y ago
I would imagine that the problems encountered by a robot engineer are quite different from those of a web startup, too.
m00x 6y ago
Could not agree more. A lot of the time the simplest, dumbest solution is the best. There are some practices that make your app easier to manage, but you need to understand in which circumstances you need to use them. A lot of the successful companies that are out there, got there from running a simple Django/RoR monolith until they were 60+ engineers.
- kls 6y ago
  My mentor was a professor at MIT for a time and then founded his own company. I joined his company as a young hot shot that thought I knew it all, I was a good hacker but not a good developer and I learned that quickly working with him and his team, but that is a story for another time. The point of my post is one thing he said to me stuck with me more than anything else in my career and that was: "Elegant code is not clever code, elegant code is code that is so simple it is clever. Strive for elegance."
MiroF 6y ago
There's just a really "in" trend right now of prematurely optimizing for scaling up to billions
prabhatjha 6y ago
Agree. You don't want to do Fashion Driven Development (FDD). You would end up chasing every shiny thing that comes out and not really master anything. Pick any one stack, build some simple projects and then expand on it. You would also want to be able to read well written code from others on github and learn from those.
- dnautics 6y ago
  by contrast don't not do something just because it's fashionable. It's worth thinking about something fashionable, because many (not all) those things are usually pointing out real pain points that people are experiencing. If something fashionable looks appealing, I would say, "drill down and understand the core of what pain point it's addressing". If you are convinced, check out "how you would have done it otherwise", and if you are happy with the fashionable thing, add it to your "fashionable thing" budget. Keep that budget tight. Be ready to revert at any time.
mttyng 6y ago
"Look into problems, you'll find solutions. Look into solutions, you'll find problems." God, I love this line.
- lioeters 6y ago
  Yeah, such pithy insight can only come from experience. Our industry, especially these days, is flooded with "solutions" that promise much - and the best ones do deliver; but what's suitable in an enterprise environment can be a huge mismatch and complexity cost for smaller companies, individuals, or for research purposes. I heartily agree with the grandparent post, to focus on what the problem domain requires, to use tools and dependencies that specifically support that goal. Too often we see a framework, library, language or tool used for the sole reason that it's what the big players use - basically driven by popularity and inertia. There are advantages to buying into an ecosystem or particular scalable approaches, but only if it suits and serves your purpose. As for writing better code - as many comments point out, the best way is to read and write lots of code, study books, follow the best works of people in the field. It helps to start with the specifics, I think, by having (or creating) a problem to solve, or a project with clear goals. One can start with the simplest, "naive" approach, to solve the immediate needs - often that involves finding off-the-shelf libraries. Then, consider ways of improving the logic, refactoring, maybe dig deeper into the libraries to understand how it's organized.

hamolton 6y ago

I would imagine that the problems encountered by a robot engineer are quite different from those of a web startup, too.

m00x 6y ago

Could not agree more. A lot of the time the simplest, dumbest solution is the best. There are some practices that make your app easier to manage, but you need to understand in which circumstances you need to use them. A lot of the successful companies that are out there, got there from running a simple Django/RoR monolith until they were 60+ engineers.

kls 6y ago
My mentor was a professor at MIT for a time and then founded his own company. I joined his company as a young hot shot that thought I knew it all, I was a good hacker but not a good developer and I learned that quickly working with him and his team, but that is a story for another time. The point of my post is one thing he said to me stuck with me more than anything else in my career and that was: "Elegant code is not clever code, elegant code is code that is so simple it is clever. Strive for elegance."

MiroF 6y ago

There's just a really "in" trend right now of prematurely optimizing for scaling up to billions

prabhatjha 6y ago

Agree. You don't want to do Fashion Driven Development (FDD). You would end up chasing every shiny thing that comes out and not really master anything. Pick any one stack, build some simple projects and then expand on it. You would also want to be able to read well written code from others on github and learn from those.

dnautics 6y ago
by contrast don't not do something just because it's fashionable. It's worth thinking about something fashionable, because many (not all) those things are usually pointing out real pain points that people are experiencing. If something fashionable looks appealing, I would say, "drill down and understand the core of what pain point it's addressing". If you are convinced, check out "how you would have done it otherwise", and if you are happy with the fashionable thing, add it to your "fashionable thing" budget. Keep that budget tight. Be ready to revert at any time.

mttyng 6y ago

"Look into problems, you'll find solutions. Look into solutions, you'll find problems." God, I love this line.

lioeters 6y ago
Yeah, such pithy insight can only come from experience. Our industry, especially these days, is flooded with "solutions" that promise much - and the best ones do deliver; but what's suitable in an enterprise environment can be a huge mismatch and complexity cost for smaller companies, individuals, or for research purposes. I heartily agree with the grandparent post, to focus on what the problem domain requires, to use tools and dependencies that specifically support that goal. Too often we see a framework, library, language or tool used for the sole reason that it's what the big players use - basically driven by popularity and inertia. There are advantages to buying into an ecosystem or particular scalable approaches, but only if it suits and serves your purpose. As for writing better code - as many comments point out, the best way is to read and write lots of code, study books, follow the best works of people in the field. It helps to start with the specifics, I think, by having (or creating) a problem to solve, or a project with clear goals. One can start with the simplest, "naive" approach, to solve the immediate needs - often that involves finding off-the-shelf libraries. Then, consider ways of improving the logic, refactoring, maybe dig deeper into the libraries to understand how it's organized.