This advice is of such low caliber and so out of touch it's almost as if you didn't even bother to open the submission before posting. It's practically useless to anyone, especially when you don't even attempt to give some motivation for it.
It's over-generalized, likely because you know only one thing or you've developed into doing only one thing and for that one thing vim is the worse choice.
That really depends on the language I think. Java/C# etc I wouldn't dare to touch without an IDE. Most of my Clojure/Lisp work is done in Emacs (with Evil for Vim bindings, without any syntax highlights). People /still/ think I'm goofy for preferring that. But, I find that if you think of programming as "creative writing" instead of engineering you enter a different, more flow-like, mindset. The IDE and all its billions of buttons just get in the way for me, while just writing s-expressions as trees (using paredit with agressive-indent) never breaks my train of thought.
"Let go of your emotions" is very superficial and not really doable with the advice that is given.
We build emotions based on the truths we perceive. The only way to healthily change emotions is to change those truths. If you feel very attached to your work and flip out (fear, anger) if someone else finds an error in it - you need to change the believe that something bad will happen to you when you make mistakes. Nobody will hit you over the head * , nobody will laugh at you * , you will not lose your job or career * . You will not be worth less as a person. You made a mistake because your brain is built in a way that allows for errors, and so is every other human brain on this planet.
* Ok somebody might do these things to you. But you will cope, and other people will help you cope.
Although I had done some programming before, I always remember the first lecture of the first year of the CS course I did where the lecturer basically concentrated on the importance of KISS (i.e. Keep It Simple Stupid). He did say that we'd probably not believe him, and of course we didn't as we were all desperate to prove how awfully clever we were. He did also say that if we stuck at things long enough we'd probably come to share his view.
How I wished I'd manage to believe that bit of advice a bit earlier in my career and saved a few projects from my zealous architectural astronautics. Well, at least that's one lesson I did eventually learn.
Can't agree with this one enough. I'm currently battling through a project full of people that are too smart for their own good and too stupid to realise it.
I had a huge argument today with someone that wanted to wrap a certain type of higher order function ("foos") in another higher order function with a particular name ("fooGenerator()") for the sole purpose of differentiating it from a different kind of higher order function in the same file ("bars").
I lost the argument. It turns out using heading comments to seperate groups of similar functions, or god forbid splitting up the 400 line file into multiple smaller ones, is too confusing and prone to errors by maintainers ("What if they put a new foo function in the section for bar functions!")
I am learning that sometimes people try to defend their ideas by coming up with ways to make their idea work. If accommodating the solution is more work than actually implementing it, it might not be the right solution.
Smalltalk plus the book about patterns. That would have been a game changer. It happened to me but years later and largely improved my coding quality on all other tech stacks
The vendor's way of doing things is just one of many possible ways, the vendor is often not right, the vendor often has their own agenda, the sky will not open and smite me if I don't go the vendor's way.
I think that 5. and 10. are not as good advice as they sound. Not many people are good teachers and if you try to learn with other, they will oftentimes attempt to do all the work, especially thinking part, for you. If they already know more, there is no way for you to match their speed and you end up just doing what they dictate - worst possible way to learn. If you want to become good, you need to spend time learning alone, when you can try out wrong path for a few minutes, solve problems independently even if it is slower, make mistakes and finding out by yourself.
It is different if people around you have good social skills on top of tech skills, but many people are not like that. A contact with community is important for motivation and having possibility to work with good quality people is indispensable. However, much of important learning happens when they are not in the room and they can not take control of keyboard and tell you solutions to problems before you had the chance to think.
I spent my first 5 years after university as an employee because "everybody has a job" and it never occurred to me that I might freelance or start my own business.
Doubly pitiful because I didn't need that much income back then, and later it became much more complicated to stop being employee due to higher cost of living in a place I moved to and due to need to support the family.
side effects are bad
code should follow data
it won't do what you intend until you've verified it
solve the problems you have, not the ones you anticipate you will have
Side effects from functions that modify global state (or importing global state elsewhere) are bad because they increase the complexity of a program in a way that can very rapidly spiral out of control. The operation of a function reading global state is no longer easily predictable and you'll be tracking hard to replicate bugs.
Better to have a function rely entirely on its arguments and to output the result as a return value.
Side effects that do things such as persisting data or producing output are - for the most part - acceptable, if they are contained in such a way that you move to as much of a 'functional' approach as soon as you can.
So reserve your side effects for the edge of your program, keep the rest as side-effect free as you can.
Now that was a little long for a bullet point list hence the abbreviated version.
Since I see no mention on wages (maybe OT) I will chime in:
Value your work, even if you think you are "still learning". I spent way too much time on under-market salaries writing good code. I wish someone had told me I could be earning 5x whilst still at uni.
Correct. I thought that somehow getting that degree suddenly qualified someone as a "real engineer". You're better once you've finnished, but your capability is still on a continuum starting prior to your first class.
Seek out well written projects and contribute to them, you'll learn far faster the principles of good software than working alone or on badly written code.
Focus on maintainability above speed, terseness, or perfection. Worse is better (<-- it took me many years to truly understand this expression)
Your plans/thoughts on any matter are strictly inferior to your thinking after putting it into practice, so do not plan too much. Instead, experiment.
I think there is value in working with poorly written code.
You will learn all the details of the language, because you will see many edge cases. You will learn about all the bad ideas (aka anti-patterns) so that you can avoid them. You will learn that comments are lies and that there are things that you can't trust. And hopefully, you will learn how to turn bad code into good code without introducing more bugs than you have fixed.
If you end up coding for a living, you are more likely to see really bad code than good code. Not only because though budget cuts and the occasional mess up by incompetent coders, but also because good code simply works, and there is no need to touch it.
I totally agree with the "experiment" part though. Everything you learn is worthless unless you actually code something, preferably something useful.
On a more technical point, I think that terseness is undervalued. The first rule of good code, for me, is "write short code". There are a few exceptions but these are just that : exceptions.
I was writing from my own regret. I feel that I learnt surprisingly little by spending a decade rewriting badly written code. I should have found out what encapsulation was years earlier. Sure, there are lessons there, but I think you will pick most of them up anywhere; you're always exposed to code you don't like.
I still value terseness highly, as in my opinion it's strongly correlated with readability (though not at all when taken to extremes), but I very often have to increase verbosity to increase maintainability. E.g. don't take shortcuts that will leak through abstractions.
Write 5 tests for a piece of code that you think is working but has no tests. You will find at least 1 bug every time.
Staying at work longer won't help you produce more and better code. Sleep and exercise will.
People who get angry about technical choices like what framework to use or what coding style or how tightly to enforce rules will flame out. Don't be that person.
If you think you need to rewrite it from scratch, think again. Look up Chesterton's Fence.
"Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood."
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."[1]
Chesterton's Fence is a great example of why code comments are critical.
If the code is doing something that isn't immediately obvious to a programmer on a deadline, there should be comments explaining why it's there.
"Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear, resulting in later programmers wasting hours or days (or worse) re-discovering the reason for something in the first place.
A counterpoint to this is that the very reason to refactor code usually is that it isn't understandable anymore. I'd rather read it in the way that you shouldn't rewrite code for which you don't understand the problem it's trying to solve.
In my experience, that part is usually much easier, since you're working in hindsight.
There's a great interview Peter Seibel did with Bernie Cosell[1], where Cosell explains that his approach to debugging usually consisted in
a) understanding what a specific piece of code is supposed to do and
b) rewriting it so it actually would do it properly.
Of course there's much to be said on when this approach is overkill and when it isn't.
> "Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear
I haven't had the luxury of working with a lot of experienced veterans, but I've seen and been burnt by rookies who couldn't be bothered to read code other people wrote or written without their favorite framework/language. No amount of comments would deflect those types.
Chesterton's Fence is a brilliant insight. Funnily enough, I learned it reading some interview in a fashion magazine. They talked about what made different designers styles is the fact that they didn't break fashion 'rules' haphazardly, rather that people should only break 'rules' they knew the purpose for and why they wanted to do so.
"9. Trying to understand everything is a lost cause. In the beginning, I tried to chase down the “why” to every problem I encountered. This isn’t necessary."
Nonsense. That is literally the worst advice you could give to an aspiring programmer. It is precisely necessary to get to the bottom of your programming problems and bugs, that's the stuff that increases your knowledge and lets you understand systems deeply. Be curious! Track things down all the way to the OS and the hardware! Recently, I just found an OS bug that negatively affected the realtime performance of our controllers. Dig deep! Never write code based on ignorance!
Lurk GitHub repos for solutions that you've done some time ago. It could clearly show what you've been doing correctly and what you could improve.
Then, if you see some place for improvement in some repo, make a pull request. Great way to learn, period.
[throwaway, first post]
usual login, not ready. AMA!
.......
elderly [1] alone [2]
early birth weight [3]
afflicted [4] , by what made me
moan [4] when the lungs [4a] I had not [5],
at the rectangle [5] I was in,
laid waste [5a] to the .C [6] [7] stuff
I though 'for the win'... [8]
1... more than 60 years old. Slept 5 1/2 hours. All I
can hope for send peaceful Taj Majal ! sic
2... I have found two others, no foundation yet. send
Lawyers! Laypersons | Pastors! betrothal-centric
spinsters? One can only dream, like last night when
I followed a nuclear submarine into a tunnel, on
a freeway where my 'papers' were left behind to be
nothing-in-shirt-pocket quizzed into Timothy Evans
of Wales (lynching) as usual...
[3] Things bother me more than full-term persons.
Proven, listable, and but for a price... but I or
one, as the singular may say, can only dream. Not
to digress, but please send...
[4] As one may conjecture, I am prone at
the present, past, and future to use expressive
words inclusive in large prose or poetry
can you hear me now
can you hear me then
in my 2 prong motel
as my ICU was dim...
and I heard not your nurses
nor your doctors at hand
as my deep breaths of drowning
crept to late to the land
to the land of our fathers
and our mothers less sin,
in 1830 humilities
of the starvings that cringe.
But I digress...
4a let us give it a rest while
we digest the above, please.
Now IF I can have your
undivided attention, gainsay,
forebearance, scripture, hymnalisms,
humilities, philanthropies,
charities, or what have you,
or what have we here, or
what I may attain or attest to
come the new day, specifically
tomorrow, let us... but pray,
and pray tell, let us
continue to # 5...
5... of course I had lungs. But surgery
atop them so I could breathe. WHAAT?
5a... I have forgotten. Please
sed 's/5a//g' omit in a /bin/rm -rf /root
from your countenances, mainstays, Maine airbnb's,
hotels of freedom, ghoul, or shackels, lords,
kings, kingdoms, or fellow travellers, not you
Mao nor Stalin or Pol, praise be...
6 .c, of course Beyond me: .h,
OO programming, Moose, Mojolicious, or what now...
but I digress, or unit test, or put the
in production server box to hum louder and
louder upon the dawn of the day and the
increased likelihood of verbose or poetic
justice or less injustice please of
what have we here, or what not, but let
us not digress, shall we? or shall we not?
BTW mom is in town, please greet her. Before
she creeps back to winter-land of high UV
and low Dec Jan temperatures to be hailed
or with hail during age 8x times of
elderly uncertainty but still worthy
of the matriarch of an early birth
weight persona of 'not now please'
who programmaatically and in a throwaway
style emits prose, poetry, but I get
beside myself, and digress, and let
us continue, if I can have your
undivided by # or macro of what have
we, or not, ... ... hmmm
8... have I won anything? contact me with
your response at a sunny day, in a sunny
place, when one is rested, and the greens
have been ingested before midafternoon, like I
am wont, indeed mandated by past illnesses and
present efforts to counteract and lessen same
and whatnot to a more health-centric intake of
diet and calorie, indeed sometimes fasting with
tea and the other morning usual hot beverage
while prose and poetry delay the plate, bowl,
silverware, or what not, or what have we
here, and let us halt while I am ahead. Or,
am out of time. I apologize for the
anonymity, terseness, read-thrice-before-comprehension,
lookup, translation, non-translation, unilateralism,
lack of detail, lack of focus group, non-seconded
peaceful [ I hope] read-in to your day, Sunny and
warm in its continuum and effortless less-afflicted
completion of your daytime tasks and evening agenda
of hope and prayer and the goodness of Man.
Thanks again for reading
Sorry, no tl:dr at this time.
My deepest and sincerest apologies to the reader.
On #3: Agreed. In my experience, every time someone comes up with some grand design before writing any code, it's built on one or more assumptions about the problem. Then work begins, and one or more of the assumptions inevitably turn out to be incorrect and the whole design gets deflated.
No, but more than one can work wonders for productivity if you are looking up documentation while coding, so you don't have to constantly alt-tab and forgetting where you were.
My productivity probably doubled when I started using the 4 window layout of sublime. I didn't realize how much mental overhead I was spending just flipping between open files.
I think this one is really a horses-for-courses situation. For me, my current setup of two 2560x1440 monitors plus a 15" laptop is absolutely optimal - I can spread a load of stuff out everywhere, flip between a few spaces, and just generally be super-productive. I can still be productive working from just the laptop in a coffee shop, but I feel very constrained and find myself shuffling windows around to get stuff done (even just writing an email whilst referring to something else), and I generally don't like it and pine for my multiple monitors, especially if I'm doing any sort of development work.
Other people seem to be able to be just as productive from a single monitor or laptop, and tabbing between things is very much just part of their workflow - I remember at one gig we bought a couple of displays for one dev and he never even bothered plugging them in.
(I don't think anyone really "needs" five monitors, though.)
To chime in anecdotally as a one-screen guy, for me it’s all about being able to unplug my laptop, switch locations, and not feel like my workflow’s crippled. I don’t like feeling anchored to my desk, or even the office as a whole.
I think alt-tab is just a poor mechanism. With fast-switching virtual desktops, I find that the advantages of multiple monitors are quite small, though I still prefer to have two.
101 comments
[ 0.36 ms ] story [ 200 ms ] threadI generally prefer vim (with syntastic, clang-format(/-diff) and my own .vimrc), but I would never write e.g., Java code using vim.
I would rephrase that as, "be pragmatic and know your options".
It's over-generalized, likely because you know only one thing or you've developed into doing only one thing and for that one thing vim is the worse choice.
Use a good (for your platform/language) IDE, not VIM.
If you aren't sure what a good IDE looks like try Intellij as a safe default.
Also it's still worth learning VIM.
Learning Vim has been one of the best professional choices I've made.
With dynamic languages I've seen a couple of IDEs that weren't able to actually deliver the refactoring or search tools they promised.
What you were left with was a large, slow editor with a poor keyboard interface.
I'd rather be closer to the operating system in Vim or Emacs and add refactoring using external tools like tern, rope, godoctor, etc.
Terminal based tools allow you to work anywhere and support easy collaboration using things like tmux.
As a perfectionnist, I had to learn this the hard way.
https://blog.codinghorror.com/quantity-always-trumps-quality...
We build emotions based on the truths we perceive. The only way to healthily change emotions is to change those truths. If you feel very attached to your work and flip out (fear, anger) if someone else finds an error in it - you need to change the believe that something bad will happen to you when you make mistakes. Nobody will hit you over the head * , nobody will laugh at you * , you will not lose your job or career * . You will not be worth less as a person. You made a mistake because your brain is built in a way that allows for errors, and so is every other human brain on this planet.
* Ok somebody might do these things to you. But you will cope, and other people will help you cope.
How I wished I'd manage to believe that bit of advice a bit earlier in my career and saved a few projects from my zealous architectural astronautics. Well, at least that's one lesson I did eventually learn.
I had a huge argument today with someone that wanted to wrap a certain type of higher order function ("foos") in another higher order function with a particular name ("fooGenerator()") for the sole purpose of differentiating it from a different kind of higher order function in the same file ("bars").
I lost the argument. It turns out using heading comments to seperate groups of similar functions, or god forbid splitting up the 400 line file into multiple smaller ones, is too confusing and prone to errors by maintainers ("What if they put a new foo function in the section for bar functions!")
Could you be more specific?
It is different if people around you have good social skills on top of tech skills, but many people are not like that. A contact with community is important for motivation and having possibility to work with good quality people is indispensable. However, much of important learning happens when they are not in the room and they can not take control of keyboard and tell you solutions to problems before you had the chance to think.
Doubly pitiful because I didn't need that much income back then, and later it became much more complicated to stop being employee due to higher cost of living in a place I moved to and due to need to support the family.
How are side effects an inherintly bad thing? They are pretty important in many cases.
Better to have a function rely entirely on its arguments and to output the result as a return value.
Side effects that do things such as persisting data or producing output are - for the most part - acceptable, if they are contained in such a way that you move to as much of a 'functional' approach as soon as you can.
So reserve your side effects for the edge of your program, keep the rest as side-effect free as you can.
Now that was a little long for a bullet point list hence the abbreviated version.
Value your work, even if you think you are "still learning". I spent way too much time on under-market salaries writing good code. I wish someone had told me I could be earning 5x whilst still at uni.
Focus on maintainability above speed, terseness, or perfection. Worse is better (<-- it took me many years to truly understand this expression)
Your plans/thoughts on any matter are strictly inferior to your thinking after putting it into practice, so do not plan too much. Instead, experiment.
I totally agree with the "experiment" part though. Everything you learn is worthless unless you actually code something, preferably something useful.
On a more technical point, I think that terseness is undervalued. The first rule of good code, for me, is "write short code". There are a few exceptions but these are just that : exceptions.
I still value terseness highly, as in my opinion it's strongly correlated with readability (though not at all when taken to extremes), but I very often have to increase verbosity to increase maintainability. E.g. don't take shortcuts that will leak through abstractions.
Staying at work longer won't help you produce more and better code. Sleep and exercise will.
People who get angry about technical choices like what framework to use or what coding style or how tightly to enforce rules will flame out. Don't be that person.
If you think you need to rewrite it from scratch, think again. Look up Chesterton's Fence.
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."[1]
Source - Wikipedia.
If the code is doing something that isn't immediately obvious to a programmer on a deadline, there should be comments explaining why it's there.
"Go away and think" just means the programmer who wrote it couldn't be bothered to take a couple of minutes to be clear, resulting in later programmers wasting hours or days (or worse) re-discovering the reason for something in the first place.
In my experience, that part is usually much easier, since you're working in hindsight.
There's a great interview Peter Seibel did with Bernie Cosell[1], where Cosell explains that his approach to debugging usually consisted in
a) understanding what a specific piece of code is supposed to do and
b) rewriting it so it actually would do it properly.
Of course there's much to be said on when this approach is overkill and when it isn't.
[1]: https://en.m.wikipedia.org/wiki/Coders_at_work
I haven't had the luxury of working with a lot of experienced veterans, but I've seen and been burnt by rookies who couldn't be bothered to read code other people wrote or written without their favorite framework/language. No amount of comments would deflect those types.
Nonsense. That is literally the worst advice you could give to an aspiring programmer. It is precisely necessary to get to the bottom of your programming problems and bugs, that's the stuff that increases your knowledge and lets you understand systems deeply. Be curious! Track things down all the way to the OS and the hardware! Recently, I just found an OS bug that negatively affected the realtime performance of our controllers. Dig deep! Never write code based on ignorance!
1... more than 60 years old. Slept 5 1/2 hours. All I can hope for send peaceful Taj Majal ! sic 2... I have found two others, no foundation yet. send Lawyers! Laypersons | Pastors! betrothal-centric spinsters? One can only dream, like last night when I followed a nuclear submarine into a tunnel, on a freeway where my 'papers' were left behind to be nothing-in-shirt-pocket quizzed into Timothy Evans of Wales (lynching) as usual... [3] Things bother me more than full-term persons. Proven, listable, and but for a price... but I or one, as the singular may say, can only dream. Not to digress, but please send... [4] As one may conjecture, I am prone at the present, past, and future to use expressive words inclusive in large prose or poetry can you hear me now can you hear me then in my 2 prong motel as my ICU was dim... and I heard not your nurses nor your doctors at hand as my deep breaths of drowning crept to late to the land to the land of our fathers and our mothers less sin, in 1830 humilities of the starvings that cringe. But I digress... 4a let us give it a rest while we digest the above, please. Now IF I can have your undivided attention, gainsay, forebearance, scripture, hymnalisms, humilities, philanthropies, charities, or what have you, or what have we here, or what I may attain or attest to come the new day, specifically tomorrow, let us... but pray, and pray tell, let us continue to # 5... 5... of course I had lungs. But surgery atop them so I could breathe. WHAAT? 5a... I have forgotten. Please sed 's/5a//g' omit in a /bin/rm -rf /root from your countenances, mainstays, Maine airbnb's, hotels of freedom, ghoul, or shackels, lords, kings, kingdoms, or fellow travellers, not you Mao nor Stalin or Pol, praise be... 6 .c, of course Beyond me: .h, OO programming, Moose, Mojolicious, or what now... but I digress, or unit test, or put the in production server box to hum louder and louder upon the dawn of the day and the increased likelihood of verbose or poetic justice or less injustice please of what have we here, or what not, but let us not digress, shall we? or shall we not? BTW mom is in town, please greet her. Before she creeps back to winter-land of high UV and low Dec Jan temperatures to be hailed or with hail during age 8x times of elderly uncertainty but still worthy of the matriarch of an early birth weight persona of 'not now please' who programmaatically and in a throwaway style emits prose, poetry, but I get beside myself, and digress, and let us continue, if I can have your undivided by # or macro of what have we, or not, ... ... hmmm 8... have I won anything? contact me with your response at a sunny day, in a sunny place, when one is rested, and the greens have been ingested before midafternoon, like I am wont, indeed mandated by past illnesses and present efforts to counteract and lessen same and whatnot to a more health-centric intake of diet and calorie, indeed sometimes fasting with tea and the other morning usual hot beverage while prose and poetry delay the plate, bowl, silverware, or what not, or what have we here, and let us halt while I am ahead. Or, am out of time. I apologize for the anonymity, terseness, read-thrice-before-comprehension, lookup, translation, non-translation, unilateralism, lack of detail, lack of focus group, non-seconded peaceful [ I hope] read-in to your day, Sunny and warm in its continuum and effortless less-afflicted completion of your daytime tasks and evening agenda of hope and prayer and the goodness of Man. Thanks again for reading Sorry, no tl:dr at this time. My deepest and sincerest apologies to the reader.
Sincerely.
1. Number of active users of language matter more than the language itself.
1.a Fads come and go.
2. Math matters.
3. Elaborate design/architecture before programming is a waste of time. Emphasis on elaborate, not architecture.
No, but more than one can work wonders for productivity if you are looking up documentation while coding, so you don't have to constantly alt-tab and forgetting where you were.
Other people seem to be able to be just as productive from a single monitor or laptop, and tabbing between things is very much just part of their workflow - I remember at one gig we bought a couple of displays for one dev and he never even bothered plugging them in.
(I don't think anyone really "needs" five monitors, though.)