I wish I had taken the time to understand LISP earlier.
Why?
And IMHO, design patterns make the constipation worse.
161–170 of 538 posts
I wish I had taken the time to understand LISP earlier.
Why?
And IMHO, design patterns make the constipation worse.
Sitting in front of a computer 60+ hours a week is not great for your body. Take the time to understand good ergonomics, buy yourself a great keyboard (like the Kinesis Advantage), and ditch QWERTY.
Make sure you're not the only person who can work with your code. Make yourself easily replaceable, on a project level. Otherwise you will get calls during your vacation; you may not be able to work on other projects, switch teams or even get promoted - or if you do, you will still be supporting the code you wrote years ago on the side.
There is no future in software development as a job. Move to a management position quickly, network, make friends with decision makers, don't spend too much time on crafting your skills, your reward for perfection will be more insane work and crazy interviews where one part not 100% done kicks you out. Work on your appearance, kiss up, lift, dress properly, use anti-aging cosmetics, make cool looking hairstyle, wear…
The hardest part about this (for me) is finding a project/product to begin working on.
I'm assuming you came to that sort of idea while working for others (which seems like the best way to learn).
- LISP - "how to solve it" by george poyla - asking more "why"s to problems
I spent at least five years chasing down "AttributeError: X has no attribute 'Blah'"-errors in Python at runtime, and came to think that this was what programming was. Three-or-so years ago I discovered Haskell, which transforms these types of errors into compile-time errors, preventing me from building the program as opposed to a sudden runtime crash.
I wonder just how many hours I've wasted doing this completely meaningless task. It's not really a problem while your programs stay small but, as they grow, I found it became the main source of time spent programming, taking away precious time defining the actual application logic.
Mind you, Haskell is fairly extreme in this regard, and I'm sure there are languages which take a similar approach, without the mathematical certainty of Haskell. But, as I've become used to the precision offered by Haskell, settling for something with fewer guarantees -- but more libraries and easier-to-digest documentation -- would feel like a great loss to me.
I spent a long time never bothering to master semi-advanced text editor or ide features. Like really simple stuff like moving forward/back by a word at a time, deleting a word at a time, hopping to next/prev brace/paren, renaming globally, doing everything without needing the mouse, multi-select etc. You can go even deeper and get into deep VIM style skills but there are many very easy things to learn that let you do…
I've been coding professionally for 20 years, a lot of the comments below are legit, but I figured I'd add one or two more: - As many people point out, the languages don't matter - something better and newer will come along, and you'll need to adapt, but that's not where programmers provide value - they provide value in understanding how to solve the problems that the business side is facing. It's easy to find someon…