That there is a huge amount of marketing hype that comes out of silicon valley for languages, projects, etc. and for the most part you are wasting your time to get too deeply immersed in any one thing.
What are some things you wish you knew when you started programming?
61–70 of 102 posts
Re: What are some things you wish you knew when you started programming?
#62That if I stopped, it would be 20 years before I'd be able to start again.
Re: What are some things you wish you knew when you started programming?
#631. Learn to be criticised and to gain as much knowledge from that, as possible.
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.
Re: What are some things you wish you knew when you started programming?
#64That unless you are in a pure code monkey position, programming is at most, 30% of the job and there is an array of skills that have nothing to do with programming that when mastered, will give the impression that you are an expert programmer.
I have some idea what you're hinting on but no entirely. Im in my 3rd year in and have seen a lot of bullshiting. Should I just learn to start bullshiting?
that's certainly part of it though as a freelancer this may refer to properly architecting before you write any code, managing your time, and negotiating with your stakeholder to keep the project sane/profitable
Re: What are some things you wish you knew when you started programming?
#651. Learn regex properly and thoroughly, in one go. Learning it incrementally, will take a lot more time in the long run.
2. Write code that works reasonably well, then refactor it to be smart/elegant.
Re: What are some things you wish you knew when you started programming?
#66How about:
- Its not about code, its about solving problems.
- Learn to cope with change. Programming constantly changes, make sure to deal with it and don't get your self stuck on one thing you can do. Pick the cherries out of every programming language and frameworks out there. You're a C# guy? Do some ruby, you ruby guy? Do some node.
- Don't give a shit about mainstream. Do what works for you. But keep an open mind and consider every option, and always try to investigate why stuff works a certain way.
- Dont freak out if you're lost in new things. Its normal, fork repos, join groups, irc channels get familiar with things.
- There is no end-game. If you think that you're going to be finished in a couple of years you're wrong, there is aways shit tons of new stuff to learn.
- Dont be a perfectionist, its gonna stall you and make you never deliver.
- Always deploy, refactoring shit is easier when you know what problem your code introduces, so don't optimize prematurely.
Re: What are some things you wish you knew when you started programming?
#67That unless you are in a pure code monkey position, programming is at most, 30% of the job and there is an array of skills that have nothing to do with programming that when mastered, will give the impression that you are an expert programmer.
I have some idea what you're hinting on but no entirely. Im in my 3rd year in and have seen a lot of bullshiting. Should I just learn to start bullshiting?
Another way to read this would be that you shouldn't just be the one to churn out lines of code according to a specific request.
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...
Re: What are some things you wish you knew when you started programming?
#68Earlier quoted context omitted.
"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 er…
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 th…
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.
Re: What are some things you wish you knew when you started programming?
#69side 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 are bad
How are side effects an inherintly bad thing? They are pretty important in many cases.
Re: What are some things you wish you knew when you started programming?
#70side 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 are bad How are side effects an inherintly bad thing? They are pretty important in many cases.
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.