What are some things you wish you knew when you started programming?
quora.com
quora.com
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.
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.
2. Learn to fail and feel good with that. And as above, to gain as much knowledge from that, as possible.
3. Learn to be confident enough to defend your solution.
4. Read as many non stricly technical books related to programming as possible. Ie. "The Pragmatic Programmer", "Rework", "Clean code", etc.
5. Don't take your job too serious. If you worry about your code after hours, stop! And if you can't, change your employer.
6. Everyone makes mistakes. Just try to not repeat them.
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.
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!
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.
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 haveHow 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.
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!")
I would also recommend learning how politics function in the workplace, if only so you can defend yourself from other peoples' black magic.
More often than not, you'll be well advised to first get to understand the problem you're supposed to be solving and come up with a good solution rather than what you're told at first. The XY problem[1] is not limited to technical people, it will very likely also affect your boss or your customers.
Occasionally, there's even the counterintuitive case where you can handle more use cases by deleting code, which I personally find very rewarding :)
[1]: https://meta.stackexchange.com/questions/66377/what-is-the-x...
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.
Take VERY good care of your mental and physical health. Do not overwork yourself. It's a marathon and you will overcome most challenges with time and discipline. You don't have to be a genius/prodigy.
Don't put too much pressure on yourself - and it's hard not to due to all the praising of highly successful programmers - but nobody is an overnight success.
Enjoy your time off.
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.
Also, math and logic are obviously related, but logic is not "a form of mathematics". If anything, mathematics is a form of logic.
See https://news.ycombinator.com/item?id=13713199
Also I've been posting a lot on math lately so if you want more examples and references, scroll through my HN posts and comments (I tend to cite everything so there's a ton of links in there).
Of special note, as others have started to discover, Grant Sanderson's 3Blue1Brown YouTube channel is a masterwork, an evolutionary tour de force in the way mathematical concepts and visualized and presented.
Grant wrote a custom software library (in Python, on Github) that enables him to create video visualizations to show the geometrical intuition behind abstract mathematical concepts. And this is key. Being able to visualize the geometric structure and transformations the mathematics is describing is the key that's been missing from the way math is traditionally taught, and this lack of visual intuition is why many find math so hard to penetrate.
3Blue1Brown's YouTube channel : https://www.youtube.com/channel/UCYO_jab_esuFRV4b17AJtAw
Go there first to develop your visual intuition -- watch all his videos, and then watch them again, and again -- and soon you'll discover your new, powerful mental models forming, and things that were once opaque will suddenly become clear.
Start with his "Essense of Linear Algebra" series (it's one people are usually blown away by, and it's being discussed on HN a bunch lately).
He's going to release an "Elements of Calculus" series in April, and while Calculus is usually a prerequisite to Linear Algebra, it's not critical for understanding the visualizations the way it's presented here. But if you need a refresher, MIT's "Big Picture Calculus" is great (it's linked to in the HN thread I referenced in the first paragraph).
https://en.wikipedia.org/wiki/ArsDigita
After the year ended, they released all of the video lectures online. This was back in the late 90s / early 2000s. Back then there was no YouTube, video compression sucked, and broadband was in its infancy so connections were painfully slow . To get the videos, you could try and download the massive video archive, but it took forever and I don't think I ever got the full thing. Finally at some point they started selling and shipping HDDs pre-loaded with the entire video archive.
Today we're fortunate to have a lot of high-quality course content available online. Greenspun was one of the pioneers who helped make that happen. We should all be thankful for his foresight and initiative to trailblaze that space.
Prior to ADuni, Phil put all the curriculum online for MIT 6.916 "Software Engineering for Web Applications". It was one of the first serious Web Engineering courses offered anywhere. Several other schools used the material to teach the course in their CS dept.
http://philip.greenspun.com/teaching/old-one-term-web-6916
Problem Set 4 was my favorite -- design a Knowledge Management (KM) system using metadata, and then let the computer generate the server-side code for the application automatically.
http://philip.greenspun.com/teaching/psets/ps4/ps4
The material was so new and innovative, it was the thing back in the day -- part of the foundational material programmers used as we were learning to build server-side apps in the dotcom era. The ArsDigita Community System (ACS) was one of the first big Web development toolkits, and it was built on top of AOLserver, a high-quality C server that had an embedded Tcl interpreter running inside. Greenspun is an MIT Lisp hacker, and Tcl is an embeddable language similar to Lisp. And running Tcl directly inside AOLserver was a key innovation because it made server-side scripts fast because it bypassed all the traditional CGI overhead, and it allowed you to make database calls from directly inside the server. All the architecture design choices were documented and explained in detail in "Philip and Alex's Guide to Web Publishing," which was required reading at the time.
http://philip.greenspun.com/panda/
The semester I did the self-study program, Phil had the MIT students take the final exam online via an app built on the ACS. The exam wasn't open to self-study students, but I wanted to take it for my own edification. I had become intimately familiar with the ACS code, and I found a way to to hack into the online system and took the exam under some guest account. I never found out how I did though -- I asked Phil about it one time when he came to Dallas, but he didn't remember. I can't believe that was almost 20 years ago.
I will definitely check out the MIT course. I bet that would help me retain it much better. I was also looking at the Math for Electrical Engineering & Computer Science that I think you mentioned in an earlier comment.
https://www.youtube.com/watch?v=L3LMbpZIKhQ&list=PLB7540DEDD...
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.
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.)
2. Write code that works reasonably well, then refactor it to be smart/elegant.
Learn from the Masters, do not seek advice in random people on Internet.
It is called "modeling". Pick your masters-mentors carefully.
For example we have people in my company that could do the work of tens or hundreds of people just by themselves because:
-they are incredible experienced and smart. -they know regular expressions, know how to automate everything. -they understand good design, and understand people as well as computers.
Just living around this people you will start modeling them, and doing the same they do.
But people also model bad behaviors just by proximity. Fat people use to have friends that are fat, and family members that are fat. The same happens with smokers or drug addicts. You pick from your surroundings subconsciously.
For example someone here recommends you to not use vim, use an IDE. Well , the masters I know either use vim or emacs a lot. They can use other tools like IDEs too, but instead of depending on someone else for automating the stuff they need they use to make their own tools.
Remember that no big company like Microsoft, Apple or Google are going to make your life easier for making your software multi platform for example, but for your company it could be essential. On the contrary, if you only use their tools your life will be miserable if you go against the interest of those companies.
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.
2. The design and specification stages of programming are not pointless enterprise makework, they are genuinely useful.
When writing a program, make sure you understand what you're trying to achieve in detail, and write a plan about you intend to do that.
If you don't know what you're trying to achieve (and by extension your customer/client doesn't either), schedule in some research / exploration work as the first part of your plan.
Once you have a better idea, redo your plan (and maybe your budget) and check it with your customer/client.
3. If something is going wrong, or you think something is going to go wrong, it's much better to tell someone as early as possible. Even if it's your fault, don't sit on your shame - get some help.
For example, if you're going to go over budget, you may be able to get some more budget. Or you may be able to get some features cut.
With them, you will be able to quickly and easily make your code better and better, with much less risk of regression.
As a result, the initial implementation details of your code are not very important, and you don't have to spend much time thinking about how the code might evolve in the future (which is unknowable anyway).
PS Don't spent much time testing the internals of your code. Check that the inputs and outputs are correct, as thoroughly as you can. Testing internals actually makes refactoring harder.
Could you be more specific?
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.
I 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.
As a perfectionnist, I had to learn this the hard way.
https://blog.codinghorror.com/quantity-always-trumps-quality...
That the status of being a programmer would drop to subzero levels in the next two decades :S
I tend to want to know how _everything_ works; this let's me reason about anything and it helps a lot when debugging.
1) Read the first chapter to get a fair understanding of how the technology works (recently getting them for both Spring security and Hibernate search helped emensely) and;
2) A way to sanity check your stackexchange solution you'll inevitably refer to.