7 ms·

1. Writing original code. In the world of JavaScript this is both discouraged and extraordinarily feared. Do it anyway. 2. Avoiding OOP and composition early i

1. Writing original code. In the world of JavaScript this is both discouraged and extraordinarily feared. Do it anyway. 2. Avoiding OOP and composition early in my career. When you learn to focus first upon the goals of an application how things come together becomes a late triviality not worth serious consideration. 3. Know the foundations, standards, and intentions of your software environment. Hoping to bullshit your way past this with a tool is an artificial constraint that slows down delivery, limits creativity/capabilities, and severely retards performance.

xupybd 5y ago
Number 1 resonates. Front end is frameworks come with more required learning than the work required to avoid them. However they promise to work for all your problems so you can standardize your teams and projects. Only they churn so fast they're out of date after your first serious project. I'm not sure I understand number 2. I'd love to hear more.
- austincheney 5y ago
  Early in my career when I was learning to program I was discouraged by reading OOP code. I found it hard to follow. Deciphering the value of this by just reading the code felt like trying to translate some lost ancient language from stone tablets. The more I put off learning OOP the more it felt like unnecessary decoration. Here is an example of a real world utility item with lots of decoration: https://c2.staticflickr.com/4/3098/3142471026_1c8f659c46_b.jpg https://c2.staticflickr.com/4/3098/3142471026_1c8f659c46_b.j... I would rather do other things then spend the time digging through decoration when debugging. 4. A fourth item I should have mentioned above is avoiding long builds. Early in my career as a JavaScript developer the front end space was seen as a toy where you send the children to play. All the serious work occurred in some bloated server side Java application. The Java developers never seemed to get anything done as they were frequently waiting on builds that could last more than an hour. When this madness later crept into JavaScript via gulp, grunt, webpack I avoided it. I could not see the value in slowing down my speed of iteration. As a result my code was dramatically smaller. It contained less unnecessary bullshit. Now I have a 5 to 10 second build in my applications due to TypeScript, which does slow me down a little but it allows me to plan and scale the features of my application so much faster that it’s still a strong added value.
  - NathanielWest 5y ago
    "When this madness later crept into JavaScript via gulp, grunt, webpack" finally somebody said it
- hootbootscoot 5y ago
  not the OP, but I'll propose that the code inside methods is largely procedural code, and this is one level (what you need to learn first), and then how it's organized is a whole other world subject to much debate. (even given SOLID DRY OOP etc.)
busymom0 5y ago
Big fan of the first point. I pretty much try my hardest not to put third party libraries for tiny features. Obviously there's gotta be a balance but I don't see a point in introducing massive bloated libraries for small features.

xupybd 5y ago

Number 1 resonates. Front end is frameworks come with more required learning than the work required to avoid them. However they promise to work for all your problems so you can standardize your teams and projects. Only they churn so fast they're out of date after your first serious project. I'm not sure I understand number 2. I'd love to hear more.

austincheney 5y ago
Early in my career when I was learning to program I was discouraged by reading OOP code. I found it hard to follow. Deciphering the value of this by just reading the code felt like trying to translate some lost ancient language from stone tablets. The more I put off learning OOP the more it felt like unnecessary decoration. Here is an example of a real world utility item with lots of decoration: https://c2.staticflickr.com/4/3098/3142471026_1c8f659c46_b.jpg https://c2.staticflickr.com/4/3098/3142471026_1c8f659c46_b.j... I would rather do other things then spend the time digging through decoration when debugging. 4. A fourth item I should have mentioned above is avoiding long builds. Early in my career as a JavaScript developer the front end space was seen as a toy where you send the children to play. All the serious work occurred in some bloated server side Java application. The Java developers never seemed to get anything done as they were frequently waiting on builds that could last more than an hour. When this madness later crept into JavaScript via gulp, grunt, webpack I avoided it. I could not see the value in slowing down my speed of iteration. As a result my code was dramatically smaller. It contained less unnecessary bullshit. Now I have a 5 to 10 second build in my applications due to TypeScript, which does slow me down a little but it allows me to plan and scale the features of my application so much faster that it’s still a strong added value.
- NathanielWest 5y ago
  "When this madness later crept into JavaScript via gulp, grunt, webpack" finally somebody said it
hootbootscoot 5y ago
not the OP, but I'll propose that the code inside methods is largely procedural code, and this is one level (what you need to learn first), and then how it's organized is a whole other world subject to much debate. (even given SOLID DRY OOP etc.)

busymom0 5y ago

Big fan of the first point. I pretty much try my hardest not to put third party libraries for tiny features. Obviously there's gotta be a balance but I don't see a point in introducing massive bloated libraries for small features.