The true language of computing is mathematics, and its power and beauty are masked to those who cannot speak it. Programming languages are powerful tools for communicating ideas and encoding the language of mathematics. You can use these tools to shovel bits around without understanding the language, but you won't be able to see or say much unless you become fluent. Creative expression comes with fluency, and fluency requires the perspective unlocked through deep understanding. Becoming fluent in the language of math is the rite of passage one must cross to receive its true potential.
What are some things you wish you knew when you started programming?
51–60 of 102 posts
Re: What are some things you wish you knew when you started programming?
#52The true language of computing is mathematics, and its power and beauty are masked to those who cannot speak it. Programming languages are powerful tools for communicating ideas and encoding the language of mathematics . You can use these tools to shovel bits around without understanding the language, but you won't be able to see or say much unless you become fluent. Creative expression comes with fluency, and fluenc…
Any recommendations of how to get at this as a self-taught programmer? I've picked up books on combinatorics and discrete math, but I still feel very far removed and don't know how to really take an interest and make the connection.
Re: What are some things you wish you knew when you started programming?
#53The true language of computing is mathematics, and its power and beauty are masked to those who cannot speak it. Programming languages are powerful tools for communicating ideas and encoding the language of mathematics . You can use these tools to shovel bits around without understanding the language, but you won't be able to see or say much unless you become fluent. Creative expression comes with fluency, and fluenc…
Logic more so than mathematics. Mathematics as a means to achieve efficiency, which is an afterthought most of the time. Most working programmers don't need more than a basic understanding of algebra.
Re: What are some things you wish you knew when you started programming?
#54That 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.
Yeah, IMO it's mostly about convincing non-technical people that, while they know what they want, you know what they need and are able to provide it. If you're not doing this, your boss is.
Re: What are some things you wish you knew when you started programming?
#55> 7. You don’t need 5 monitors. 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.
Re: What are some things you wish you knew when you started programming?
#56I don't agree with 9. I tend to want to know how _everything_ works; this let's me reason about anything and it helps a lot when debugging.
Personally, I've found that getting that just getting a book on the technology as a resource accomplishes two things --
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.
Re: What are some things you wish you knew when you started programming?
#57Seek 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 ( 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.
Re: What are some things you wish you knew when you started programming?
#58That 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?
Re: What are some things you wish you knew when you started programming?
#59> 7. You don’t need 5 monitors. 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.
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.)
Re: What are some things you wish you knew when you started programming?
#60Write 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 scra…
"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 the reason for something in the first place.