From 5762f3e23079e39f28827ed96bdf3e4cf35c708d Mon Sep 17 00:00:00 2001 From: Bridger Brown <106130443+bridgerbrown@users.noreply.github.com> Date: Sun, 1 Oct 2023 14:59:59 -0700 Subject: [PATCH] Fixed grammar issues --- ...023-09-17-how-to-be-a-good-programmer.html | 68 +++++++++---------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/posts/2023-09-17-how-to-be-a-good-programmer.html b/posts/2023-09-17-how-to-be-a-good-programmer.html index 654986e..2bdd63f 100644 --- a/posts/2023-09-17-how-to-be-a-good-programmer.html +++ b/posts/2023-09-17-how-to-be-a-good-programmer.html @@ -28,17 +28,17 @@
-Programming is a very unique activity in the spectrum of human activities. On the one hand there +Programming is a very unique activity in the spectrum of human activities. On the one hand, there are activities which are done purely for the love it - they are artistic activities, like creating music, or doing painting. While some musicians or painters do become famous and rich, -music or painting in itself is not something which directly brings economic gains to the society in the way -that a loaf of bread (which can be eaten) or a brick (which is used to build house) does. Musicians +music or painting in itself is not something which directly bring economic gains to society in the way +that a loaf of bread (which can be eaten) or a brick (which is used to build a house) does. Musicians and painters, at least the best of them, practice their art for the love of it.
A lot of Mathematics falls in this domain too. While Mathematics has a lot of practical uses, mathematicians -push the boundaries of human knowledge for its own sake, and it is lucky coincidence that advanced +push the boundaries of human knowledge for its own sake, and it is by lucky coincidence that advanced Mathematics is sometimes useful in other areas of human activity, particularly Physics. As an aside, A Mathematician's Apology is a good book to explore thoughts on pure vs applied Mathematics. @@ -47,37 +47,37 @@
On the other hand, there are mundane activities like business and politics. People don't do business to practice business for its own sake, their goal is to make money. Politicians don't -do politics for its own sake, their goal is mostly power, money and sometimes hopefully to serve the country. +do politics for its own sake, their goals are mostly power, money, and hopefully sometimes to serve the country.
-Programming is unique in the sense that while we don't write program just for the sake of programming, -but still programming is an art - the feeling of -joy that you get when you write a good program is similar to the joy you get when you create good music -or painting or prove a nice theorem, and it is unlike the joy that you get when you succeed in +Programming is unique in the sense that while we don't write programs just for the sake of programming, +programming is still an art. The feeling of +joy that you get when you write a good program is similar to the joy you get when you write good music, +create a beautiful painting, or prove an impressive theorem, and it is unlike the joy you get when you succeed in business or politics. There is something in programming that is soothing to the soul.
-I don't have a strong intuition about where to place other engineering activities in this spectrum - +I don't have a strong intuition of where to place other engineering activities on this spectrum - is designing a car (mechanical engineering), or a rocket (aerospace engineering) also an artistic -activity? May be, but my intution is that software engineering is just more artistic than other, -more physical branches of engineering. +activity? Maybe, but my intution is that software engineering is just more artistic than others, +more than physical branches of engineering.
So, software engineers are in a unique position - they can do something artistic while producing something which is directly useful to the society. This also makes their position precarious. If -they focus only on the art part of it, then in a corporate setting they would be too slow and -that would harm them. If they focus only on the delivery part of it, forgetting art completely then -in the long term they would remaing poor programmers and that would hurt delivery part of their +they focus only on the art side of it, then in a corporate setting they would be too slow and +it would harm them. If they focus only on the delivery part of it, forgetting art completely, then +in the long term they would remaing poor programmers and that would hurt the delivery side of their work.
The struggle to become a good programmer is that of appreciating and honing the art part of -programming more and more (which brings business benefits in the long term, and makes programming -more pleasing) while doing a good job on day to day delivery. +programming more and more (which brings business benefits in the long term and makes programming +more pleasing) while doing a good job on the day to day delivery.
Alright, with this preamble, let's get to the topic of the article - how to become a good programmer. @@ -97,15 +97,15 @@
There are two kinds of people in technology. A large majority of them write programs, compile and run them. -And a small minority write compilers. Language design is largely influenced by the latter group of people. +Then a small minority actually write compilers. Language design is largely influenced by the latter group of people. Just as car mechanics always look at a car in a deeper way than the rest of us (they would use some technical -jargons that others don't get), and astronomers looks at night sky in a different way than the rest of us, +jargons that others don't get), and astronomers looks at the night sky in a different way than the rest of us, compiler writers have a deeper appreciation of programming languages.
@@ -121,12 +121,12 @@Programs get compiled to an architecture - sometimes to native architecture as in the case of C, and at other -times to a virtual machine architecture (like in Java to JVM and in Python to python virtual machine). It +times to a virtual machine architecture (like in Java to JVM and in Python to Python virtual machine). It is good to understand this architecture to have a better appreciation of the languages itself.
-For instance, having an appreciation that instruction of integer multiplication and floating point multiplication +For instance, having an appreciation of the fact that instruction of integer multiplication and floating point multiplication are different would make one understand why int and float are two different data types. And understanding caches would help one understand why matrix multiplication done in a certain way is faster than when done in another way. @@ -139,7 +139,7 @@
-I cannot precisely defend why it makes one a good programmer but looking at an intermediate stage +I cannot precisely define why it makes one a good programmer, but looking at an intermediate stage between source code and machine code certainly increases one's apprecation of what is going on.
@@ -147,16 +147,16 @@Having an understanding of runtime environment helps you understand what is going on beneath the hood. For instance, understanding how garabage collection works in Java and why Global Interpretor Lock -hurts python performance. +hurts Python's performance.
-Reading history of anything equips one with a different take. Evolution of languages has been happening +Reading the history of anything equips one with a different take. The evolution of programming languages has been happening along with, and partly as a response to, increasing processing power and increasing penetration of -computing in the society. Thus, while initial languages were closer the hardware, newer languages -are more user friendly, and useful despite being inefficient because the hardware has become faster anyway. -User friendliness of these languages have lowered the barriers to entry for programming. +computing in the society. Thus, while initial languages were closer to hardware, newer languages +are more user friendly and useful, despite being inefficient because the hardware has become faster anyway. +User friendliness of these languages has lowered the barriers to entry for programming.
For many developers, their coding cycle looks like the following. They are building some new functionality. Step by step they build it up. At each step along the way they test their code (mostly via print statements). -Many times they encounter bugs which are not easy to resolve. They spend a lot of time find the logical +Many times they encounter bugs which are not easy to resolve. They spend a lot of time trying to find the logical error they have made. Finally, they are able to resolve all the known errors and check that the code correctly works for a all plausible use cases. At that part, they declare victory, delete extraneous print statements, perhaps do a bit of code clean up and send the code for review.
-Just a hungry man cannot think of God, a developer who has not implemented the feature correctly cannot think -of elegant code. The process of writing elegant code begins only after you have got the functionality out -of the way. So, once you have implemented the feature, that is a good time to take a look if the everything +Just as a hungry man cannot think of God, a developer who has not implemented the feature correctly cannot think +of elegant code. The process of writing elegant code begins only after you have gotten the functionality out +of the way. So, once you have implemented the feature, that is a good time to take a look to see if everything can be done in a far better way. Often, I have found that only when you finish writing the code for a problem do you really understand the structure of the problem in the first place. And when you understand that, you can often do everything a bit differently, which is more elegant. @@ -189,14 +189,14 @@
Very often I have seen developers trying to "future proof" their -code. They develop extensive class hierarchies and needless abstractions justification for which is "in future +code. They develop extensive class hierarchies and needless abstraction justification because "in the future when we need to do so and so, it will be very easy". In practice, the future turns out to be very different from what the developer imagined and new people reading the code waste time in understanding the abstractions for no benefit.
-So, the code we write should be elegant for our current needs, not for enabling us to do better job +So, the code we write should be elegant for our current needs, not for enabling us to do a better job in future. Only when it is very obvious that the requirements have moved in a way that existing abstractions are no more suitable, should we strive to change them.