91–100 of 207 posts
The more interesting endeavor is to make the complicated simple.
Been programming over 30 years, since I was 8 years old and my dad’s coworker gave me his old BASIC programming books and I was hooked. I have always found programming easy, and still do. It is just fun, and I still love learning new languages and tools and paradigms. It is still my favorite hobby. However, WORK is hard. Dealing with office politics and changing priorities and bad leadership and meetings and TPS repo…
If you are finding programming easy doesn't that just mean you aren't trying hard enough? There are tons of unsolved problems, tools that aren't optimal, and products that don't work as well as they should. If fixing those things were easy for you, you would be a billionaire.
I'm not sure you would approach any of those with programming. Once you have solved the problem, determined how to optimize the tools, or found a way to make a product work better then you might turn to programming to implement your discovery, sure, but programming alone won't get you there.
Earlier quoted context omitted.
Most of those processes, tps reports, jira and other annoyances is because in a programming environment you literally have too many cooks in the kitchen. Every programmer can create the system from scratch, so to prevent them from doing so, we have to make it super annoying. Basically it's a people problem. The most incredible work happens in the first 3 months by a lone developer green-fielding with no boundaries. T…
“ The interaction of two programmers looking over a program that either one of them could have worked out is entirely different from the interaction of two programmers working on separate parts of a whole which is too great for either one to produce. The difference lies in the way conflicting demands are resolved. In the first case, resolution of conflict is the thinking process of one person—aided perhaps by other p…
https://en.m.wikipedia.org/wiki/Peopleware:_Productive_Proje...
Been programming over 30 years, since I was 8 years old and my dad’s coworker gave me his old BASIC programming books and I was hooked. I have always found programming easy, and still do. It is just fun, and I still love learning new languages and tools and paradigms. It is still my favorite hobby. However, WORK is hard. Dealing with office politics and changing priorities and bad leadership and meetings and TPS repo…
However, programming will be hard if the thing that you are programming for has enough (essential) complexity and there is no way around it, even if you are experienced. Some examples where I found programming to be very hard include
- Programming a microcontroller that has a 1400-page reference manual and many conceptually difficult things that you would have to manage.
- Taking pseudocode of an algorithm from a research article and turning it into professional, commercial code while handling all the edge cases that were never considered in the article. I believe it was Donald Knuth who claimed that the correct implementation of some 50-line sort algorithm took 30 years to get it finally right.
- Constructing the state machine of a complex-enough system and implementing it in code. Take David Harel's Statechart paper, for example, where he builds the state chart of a "simple" Casio wristwatch. Building such a state machine and implementing it in code will always be hard, even if you have more modern tools.
So, to reiterate, programming does not just mean downloading some npm library and making API calls to it. When I see comments like "Programming now for 30 years and it's a breeze to pick up new frameworks and ideas", I wonder if people have a very narrow definition of what programming is.
"But wait, you have more experience and we have better tools!"
Yes, but programming stacks used to be simple and well-defined.
HTML/CSS/jQuery + a LAMP stack or ROR could get you a long way. Baring IE bugs, it was possible to 1) develop without constantly using Google 2) understand what every line of code does 3) be quickly productive, which was very satisfactory.
These days, starting and deploying a new project involves a kitchen sink with a bazillion tools, languages and 3rd-party dependencies. And when something doesn't work the way you expect it to, it's a ton of work to find the needle in the haystack, with so many layers to understand, especially since they don't share any consistency whatsoever.
I doubt it. Nowadays to start programming you need to set up complicated run environments and other setups even before you begin to code something. Programs are more complicated, such as apps which involve front-end and back-end. These games that claim to help with programming only hide the actual programming or abstraction . People think they are coding but are not really coding. Moving boxes around is not coding.
Been programming over 30 years, since I was 8 years old and my dad’s coworker gave me his old BASIC programming books and I was hooked. I have always found programming easy, and still do. It is just fun, and I still love learning new languages and tools and paradigms. It is still my favorite hobby. However, WORK is hard. Dealing with office politics and changing priorities and bad leadership and meetings and TPS repo…
Most of those processes, tps reports, jira and other annoyances is because in a programming environment you literally have too many cooks in the kitchen. Every programmer can create the system from scratch, so to prevent them from doing so, we have to make it super annoying. Basically it's a people problem. The most incredible work happens in the first 3 months by a lone developer green-fielding with no boundaries. T…
> As "wordsmiths," programmers often neglect reading. However, reading is an essential part of quickly improving your programming skills. I'm always surprised to hear that most programmers dislike code reviews. I've found code reviews to be one of the most useful ways to learn new design patterns and language features. I personally believe that adopting a mindset of curiosity helps make code reviews enjoyable rather…
The biggest issue with code reviews as a process is it's always positioned as being adversarial. Often, you set up a pull/merge request, and someone later does a review, but it's not personal, it's cold and blunt data. Even with a reviewer who has the best intentions, it's tough.
Pair programming and review can _help_ with this. Sit with the person who wrote the code, and review together.
I'm with you, code reviews are great for learning, but like you said, you need to see it as a tool to help you succeed and learn, and not as a tool to show you how you're wrong.