What programming is not about
Programming is not about mashing the keyboard and typing as fast as possible. It is not about religiously ...
For further actions, you may consider blocking this person and/or reporting abuse
I often use the analogy with writing a story. Learning to write code is easy, just like writing a story.
But programming/software development is more like write a good book. I'm not even talking about a Lord of the Rings, or War and Peace. Although that it quite often what others expect.
Thank you.Great writing. One of the reasons: no jargon.
I think that this is the most accurate and insightful article about programming that I've ever read. Thank you.
Thank you! That means so much to me.
Coding can't simply be categorized as "hard" or "easy"...
Coding (which is one component of the discipline known as software engineering), challenges us everyday; sometimes those challenges are hard and complex, sometimes easy and simple... but always doable.
We learn new lessons (and relearn old lessons) as we work thru those challenges; we learn how to avoid the new pitfalls that we just fell into; we learn new debugger features; we gain some new insight (that may or may not have been previously obvious); we begin to see more clearly how this slab of code really works (killing off any prior assumptions).
We apply known principles and our inginuity to produce the simplest and most elegant solution.
And, then we figure out how to test this; we also have determine how it wil impact the rest of the code/system. And, not only do we attempt to make this code piece better and stronger, but we give consideration to the next engineer by inserting just the right comment (no more, no less); and by writing a concise but easily understood git message; and by completing the review/pull request in the Jira ticket; and by explaining to the QA person how to get this code path to ececute so they can test it.
So, coding (SE) is not "hard"... it is "involved", same as any engineering discipline (consider what MechEng's do before they even start doing a bridge).
:)
I really love the conclusion but programming is not hard: can be boring for some task or project but most of the time is exciting, fun and challenging. I am programming since the 80 and manage teams since the middle of 90 and on my experience on a team if some programmer found the task 'hard' my suggestion is that he change his job.
Yup, I agree with saying that programming is fun and challenging. I think that's the reason why I love it so much: it just challenges me to think and solve problems in creative (and sometimes unorthodox) ways.
However, I can't deny the fact that programming is indeed "hard". The amount of things we have to worry about every day is astonishing (as proven by the many facets of programming I mentioned).
From the outside looking in, programming is one of the most cryptic professions out there. To us, it may not be "hard", but it definitely is challenging (to the point that it is a difficult profession to be in if one can't handle the stress that comes with it).
Dijkstra has written quite a few articles worth reading:
Two views of programming, by Edsger W. Dijkstra
In the world around us we encounter two radically different views of programming:
View A: Programming in essence is very easy.
View B: Programming is intrinsically very difficult.
Needless to say which view Dijkstra held.
This is a really great and thoughtful post. Thank you for this. This is super informative for all of those curious about what we do as programmers.
Where's the business knowlege in your list ?
If you don't know what your target is all the other items in your list are useless 😬
Better get on board a ship w/o a compass and a sextant you would have better chances
to get to your destination...
Surely I couldn't write everything about what goes into programming without overbloating my article. And I believe that including business knowledge may seem too "meta" on the topic programming. In the article, the section on teamwork already seems "meta" enough due to it not exactly being "programming", per se. I didn't want to drag out the "meta"-ness, which is why I only primarily focused on the direct aspects of programming.
But besides that, thanks for adding something to my list! It always helps the knowledge base.
Understanding the business and how it will evolve is the hardest part to avoid
creating rigid systems.
Everything else that follows after this step is trivial.
You know what business pple complain the most about IT in general ?
That they don't understand the business and often propose solutions that suits
them but are short sighted business wise or absolutely inadequate 😬
Two lines don't 'bloat' an article...
True, but I feel like two lines don't do justice to the importance of the point you're raising.
Don't get me wrong, I completely agree with your perspective, but I think it's better if the business side of programming is discussed as a separate article of its own, and not just a skim-through in an article such as mine because, again, it wouldn't do justice to its significance in constructing an overall sustainable, future-proof business model.
What I really wanted to focus on in this article are the direct aspects of programming, not necessarily the business side of things. Programming is programming; running a business is another, which is why I feel the topic should have a whole article of its own.
Perhaps you can write an article about it? I am definitely not qualified enough to discuss such matters, and I would love to see how you could expound on it.
I really enjoy the lecture, It is true that the challange in this field is very hard but the reward about it is very grateful, when you see you hard work published or running in a device etc. Many thanks for the article.
Thanks for such stuff about programming. One piece missing in this article is the hustle and the difficulty one ought to go through to get hired. I mean the white board coding interview. Though one will not be using this stuff much in his/her daily work. Without passing this white board coding test, one will not be able to get hired. To pass this test, one must be competent in data structures and algorithms. This competence requires several hours of practice, practice and practice.
It really confuses me why front-end developers need to learn complex algorithms just to get hired. It is by far one of the greatest mysteries of life.
Regarding "a missing piece in this article", I didn't really want to jump into the rabbit hole of interviews because it would make my article longer than it should be. Furthermore, I only wanted to discuss what programmers do in their jobs, not before they get their jobs, because that's a whole new beast of a topic itself. If I had added interviews in my article, it would be so bloated and the main message—which are the facets of programming we have to worry about daily—would be lost.
The Hollywood depictions are certainly laughable, but I'm not sure that editor familiarity is a reasonable target to be included here. Sure, being familiar with one's tools is not directly about programming itself, but it does, in so many cases, have a positive correlation to being a capable and passionate programmer.
People who touch type fast and use Vim keybindings every day are far more likely to be people who are really interested in the craft of programming, so that they actually went out and spent their own spare time to learn the skills. Would you trust somebody who types very slowly with only two index fingers to be a great programmer? Very unlikely I'd say. The same goes for how you wouldn't trust a carpenter who has all his saws rusty.
This piece does a reasonable job in explaining programming to beginners but one might have gone a bit overboard here. I also remember reading from a prominent programmer that great (some say "10x") programmers for a language are great largely because they are so familiar with that language that they've internalized the API, libraries, documentation etc. Those factors are all very relevant to programmer efficiency.
Great piece of work. Very insightful and valuable content which must be read by all programmers.
Thank you so much. In this article, I really just wanted to highlight how difficult this profession is, and how we shouldn't be taking developers for granted because of it. More often than not, people are unforgiving when they encounter a bug in an app or anything like that. In some instances, they unleash their full wrath. Though understandable, I feel that a developer is already going through a lot of stress in the workplace alone (as indicated by the many facets of programming he/she has to worry about). Sometimes, we do not give enough credit to developers, the unsung heroes of the modern world, which is why I wrote this article. I hope my message of understanding their struggles came across well.
Yeah, absolutely true.
Good overview! Virtually impossible to master it all, especially since it's always changing ...
True words 😎😃
Thanks for the comprehensive article,programming is more than people of the outside field see it to be. I have to close my system for some hours to think well
You did a great job of capturing specifics and generalities. What specialized roles have you had? Which order should each of these things be taught to new devs?
I have never really been in a professional setting yet. I'm still doing my studies. The content of my article comes from experience and observations in the community if you're wondering.
And I think I could say that I have a specialized role in front-end and back-end web development, at least in my personal projects. No source of income as of yet since I'm learning the ropes, but I'll get there soon enough. 😁
For new developers, it's always best to work on your attitude first. It's hard to work with a stubborn person in a team. Once you're sure that you have a great attitude and an amazing willingness to cooperate with a team, I'd say they should learn the basics of a programming language first. Then, they apply their logic and newfound knowledge to create their own applications and algorithms. Once you have the hang around the workflow, it's time to organize and structure your app. For that, it's important to focus on readability, modularization, and maintainability. After that, I'd say they should learn how to read documentation next because that's a very important skill to have. Once achieving competence in the previous facets, I believe it's time to learn a bit about user experience and UI design. Finally, performance comes last because it's not really something a beginner should worry about for the time being. Performance and optimization are pretty advanced topics that require a substantial amount of knowledge about a programming language to be aware of all the tips, tricks, and hacks available to you.
So if I were to order each of these things, I'd say:
Nice concise article, i thank programmers for their underappreciated contribution to our society. <3
Bravo! I really enjoy your style of writing, @Some-Dood.
I didn't really expect to be commended for my style of writing in this article. Well, that's a first. Thanks! 😀
We all start from there, my friend. I'm glad you pushed through!
lol to know someone put tracker on this page haha
This is Warming and encouraging. I feel more encouraged to carry-on even better. Thank you!
This comment made my day even better!