!rant

Advice
[1] Don’t panic! All will become clear in time.
[2] You don’t have to know every detail of C++ to write good programs.
[3] Focus on programming techniques, not on language features.

just read in "A Tour of C++11" by Bjarne Stroustrup

It's not just true for C++, that's true for everything

I'm looking forward to natural language programming.

The ability to code by explaining what you want to happen and having a neural network work out the fine details in an optimal fashion with evolutionary techniques.

I look forward to the super AI. I don't think they will necessarily be evil, however above a certain point we would seem like ants to them... And when was the last time you checked if there was an ant where you were to put your foot? It's not malicious... It's just not worth your or their time.

How I met python
[long read but worth]

There's nothing wrong with falling in love with a programming language for her looks. I mean, let's face it - Python does have a rockin' body of modules, and a damn good set of utilities and interpreters on various platforms. Her whitespace-sensitive syntax is easy on the eyes, and it's a beautiful sight to wake up to in the morning after a long night of debugging. The way she sways those releases on a consistent cycle - she knows how to treat you right, you know?

But let's face it - a lot of other languages see the attention she's getting, and they get jealous. Really jealous. They try and make her feel bad by pointing out the GIL, and they try and convince her that she's not "good enough" for parallel programming or enterprise-level applications. They say that her lack of static typing gives her programmers headaches, and that as an interpreted language, she's not fast enough for performance-critical applications.

She hears what those other, older languages like Java and C++ say, and she thinks she's not stable or mature enough. She hears what those shallow, beauty-obsessed languages like Ruby say, and she thinks she's not pretty enough. But she's trying really hard, you know? She hits the gym every day, trying to come up with new and better ways of JIT'ing and optimizing. She's experimenting with new platforms and compilation techniques all the time. She wants you to love her more, because she cares.

But then you hear about how bad she feels, and how hard she's trying, and you just look into her eyes, sighing. You take Python out for a walk - holding her hand - and tell her that she's the most beautiful language in the world, but that's not the only reason you love her.

You tell her she was raised right - Guido gave her core functionality and a deep philosophy she's never forgotten. You tell her you appreciate her consistent releases and her detailed and descriptive documentation. You tell her that she has a great set of friends who are supportive and understanding - friends like Google, Quora, and Facebook. And finally, with tears in your eyes, you tell her that with her broad community support, ease of development, and well-supported frameworks, you know she's a language you want to be with for a long, long time.

After saying all this, you look around and notice that the two of you are alone. Letting go of Python's hand, you start to get down on one knee. Her eyes get wide as you try and say the words - but she just puts her finger on your lips and whispers, "Yes".

The moon is bright. You know things are going to be okay now.

I try and try and try to teach my coworker critical thinking skills, proper programming techniques, and standard git etiquette. Then I add 4 booleans to solve one problem, use strings instead of ints to find unique SQL Server entities, and push right to the development branch.

I am a real asshole, but at least I am not fake.

TL;DR:
JuniorDev ignores every advice, writes bad code and complains about other people not working because he does not see their result because he looks at the wrong places.

Okay, so I am really fed up right now.
We have this Junior Dev, who is now with us for circa 8 months, so ca. a year less than me. Our first job for both of us.
He is mostly doing stuff nobody in the team cares about because he is doing his own projects.

But now there's a project where we need to work with him. He got a small part and did implement that. Then parts of the main project got changed and he included stuff which was not there anymore. It was like this for weeks until someone needed to tell him to fix it.
His code is a huge mess (confirmed by senior dev and all the other people working at the project).

Another colleague and me mostly did (mostly) pair programming the past 1-2 weeks because we were fixing and improving (adding functionality) libraries which we are going to use in the project. Furthermore we discussed the overall structure and each of us built some proof-of-concept applications to check if some techniques would work like we planned it.
So in short: We did a lot of preparation to have the project cleaner and faster done in the next few weeks/months and to have our code base updated for the future. Plus there were a few things about technical problems which we need to solve which was already done in that time.
Side note: All of this was done not in the repository of the main project but of side projects, test projects and libraries.

Now it seems that this idiot complained at another coworker (in our team but another project) that we were sitting there for 2 weeks, just talking and that we made no progress in the project as we did not really commit much to the repository.
Side note: My colleague and me are talking in another language when working together and nobody else joins, as we have the same mother tongue, but we switch to the team language as soon as somebody joins, so that other colleague did not even know what we were talking about the whole day.

So, we are nearly the same level experience wise (the other colleague I work with has just one year more professional experience than me) and his work is confirmed to be a mess, ugly and totally bad structured, also not documented. Whereas our code is, at least most of it, there is always space for improvement, clean, readable and re-useable (confirmed by senior and other team members as well).
And this idiot who could implement his (far smaller part) so fast because he does not care about structure or any style convention, pattern or anything complains about us not doing our work.

I just hope, that after this project, I don't have to work with him again soon.
He is also one of those people who think that they know everything because he studied computer science (as everybody in the team, by the way). So he listens to nothing anybody explains to him, not even the senior. You have to explain everything multiple times (which is fine in general) and at some points he just says that he understood, although you can clearly see that he didn't really understand but just wants to go on coding his stuff.
So you explain him stuff and also explain why something does not work or is not a good thing, he just says "yes, okay", changes something completely different and moves on like he used to.

How do you cope with something like this?

Recursion is an important programming technique, in which a function calls itself.

Here’s the second book for today.

Another small 100 page or so book.

It’s called advanced programming techniques, personally I don’t like the title, I don’t consider most of the items in here advanced, I would consider them more “better ways of solving a problem”, they do talk about recursion and linked lists, so I guess that could be a little advanced.

But like table based solutions is not advanced it’s just a technique that allows for simpler, scale able and main table code.. I been doing it for a long time, most easiest way to determine if something can turn into a table solution is look for a function that has a bunch of calls to the same function or something of that nature lots of repeated code with slight changes in a function or range of functions .. those of simplist way of “tablefiying”a solution I will picture the example from the book below.

The book, is all in java except for linked lists Thats in C..

But anyway this book is a great quick reference book, into the pile with programming pearls book, and those like that.

In a universe where JavaScript was never invented, the world of programming might look vastly different. Perhaps another programming language would have taken its place, or multiple languages would have coexisted in a more harmonious ecosystem.

Without the challenges posed by JavaScript, web development may have been smoother and more streamlined. Websites could have been faster and more responsive, without the need for complex optimization techniques. There might have been fewer security vulnerabilities to worry about, and the web could have been a safer place for users.

In this utopian world, developers would have had more time to focus on building great user experiences and innovative features, rather than battling with cross-browser compatibility issues and JavaScript quirks. The internet would have been a more accessible and inclusive place, with fewer barriers to entry for those who want to build and create.

Overall, a world without the horrors of JavaScript would have been a world with less frustration and more possibilities.

(Fooling around with ChatGPT)

So, I departed for a month long Erasmus in Portugal and got to work for an education related business. From day 1, all my tasks consisted in transcribing data from paper to excel sheets, and then using that data for various different tasks. It became obvious that I wouldn't have had much programming to do by default, so I started creating a series of Python scripts to automate part of my work or aid me in some bothersome areas of it, and what at first seemed a grueling series of boring and repetitive work soon actually became fun. From this point on I challenged myself to make the scripts better and better under as many aspects as possible. I eventually ended up concluding all my daily tasks in a matter of 15 to 30 minutes everyday, as that's the time it took to adapt the scripts to the new document formats of the day :P Jokes aside, this truly proves a point though: small businesses like this one, that very much depend on manual labor for tasks that can easily be automated by 50 lines of code, truly would benefit from a prepared IT and development team, and it shocked me to see how little these guys know, and are even afraid at times, about innovative techniques to speed up work substantially. Truly a great and humbling experience for very young devs like me :)

I am 17 years old, and I am trying to learn programming. I am currently trying to learn something in BASH. I have also used some JavaScript and Python to get a grasp of some concepts.

It is very satisfying when I am in the mood, but I often find it hard to find motivation to learn. Does anyone have any advice for studying techniques? General advice would also make me very grateful! :-)

I hope this is OK to post here..

Anyone have success dealing with nondevs and explaining the “zone” and to not interrupt if I’m programming and would like to share their techniques? I’m the only developer in the company I work for and all my coworkers/bosses don’t get it and even give me grief about using headphones in the office. I’ve actually gone into vacant offices off the open floor plan to try and program uninterrupted, but I don’t know how long I can keep that up without catching flak.

Here comes lots of random pieces of advice...

Ain't no shortcuts.

Be prepared, becoming a good programmer (there are lots of shitty programmers, not so many good ones) takes lots of pain, frustration, and failure. It's going to suck for awhile. There will be false starts. At some point you will question whether you are cut out for it or not. Embrace the struggle -- if you aren't failing, you aren't learning.

Remember that in 2021 being a programmer is just as much (maybe even moreso) about picking up new things on the fly as it is about your crystalized knowledge. I don't want someone who has all the core features of some language memorized, I want someone who can learn new things quickly. Everything is open book all the time. I have to look up pretty basic stuff all the time, it's just that it takes me like twelve seconds to look it up and digest it.

Build, build, build, build, build. At least while you are learning, you should always be working on a project. Don't worry about how big the project is, small is fine.

Remember that programming is a tool, not the end goal in and of itself. Nobody gives a shit how good a carpenter is at using some specialized saw, they care about what the carpenter can build with that specialized saw.

Plan your build. This is a VERY important part of the process that newer devs/programmers like to skip. You are always free to change the plan, but you should have a plan going on. Don't store your plan in your head. If you plan exists only in your head you are doing it wrong. Write that shit down! If you create a solid development process, the cognitive overhead for any project goes way down.

Don't fall into the trap of comparing yourself to others, especially to the experts you are learning from. They are good because they have done the thing that you are struggling with at least a thousand times.

Don't fall into the trap of comparing yourself today to yourself yesterday. This will make it seem like you haven't learned anything and aren't on the move. Compare yourself to yourself last week, last month, last year.

Have experienced programmers review your code. Don't be afraid to ask, most of us really really enjoy this (if it makes you feel any better about the "inconvenience", it will take a mid-level waaaaay less time to review your code that it took for you to write it, and a senior dev even less time than that). You will hate it, it will suck having someone seem like they are just ripping your code apart, but it will make you so much better so much faster than just relying on your own internal knowledge.

When you start to be able to put the pieces together, stay humble. I've seen countless devs with a year of experience start to get a big head and talk like they know shit. Don't keep your mouth closed, but as a newer dev if you are talking noise instead of asking questions there is no way I will think you are ready to have the Jr./Associate/Whatever removed from your title.

Don't ever. Ever. Ever. Criticize someone else's preferred tools. Tooling is so far down the list of what makes a good programmer. This is another thing newer devs have a tendency to do, thinking that their tool chain is the only way to do it. Definitely recommend to people alternatives to check out. A senior dev using Notepad++, a terminal window, and a compiler from 1977 is probably better than you are with the newest shiniest IDE.

Don't be a dick about terminology/vocabulary. Different words mean different things to different people in different organizations. If what you call GNU/Linux somebody else just calls Linux, let it go man! You understand what they mean, and if you don't it's your job to figure out what they mean, not tell them the right way to say it.

One analogy I like to make is that becoming a programmer is a lot like becoming a chef. You don't become a chef by following recipes (i.e. just following tutorials and walk-throughs). You become a chef by learning about different ingredients, learning about different cooking techniques, learning about different styles of cuisine, and (this is the important part), learning how to put together ingredients, techniques, and cuisines in ways that no one has ever showed you about before.

My elementary IT teacher whom I owe all my enthusiasm to introduced me to MIT Scratch, and I found the concept of chaining dumb operations to accomplish tasks fascinating. Later I learned c++ which I hated vehemently for a couple months until it clicked. After that I studied C#, which I managed to use for over a year before realising what copy by reference actually means. With that realization my understanding of programming languages was essentially complete and since then I have only learned techniques and tricks and languages that add few new ideas, and I don't expect anything to fundamentally change my understanding of programming. All of that was 5 years ago BTW.

Scott Meyers.
He's just amazing. The way he thinks, he teaches, is absolutely wonderful. He's inspired me on many occasions.

Herb Sutter.
Absolute beast of a programmer. His guru of the week series is a simple but effective way to communicate concepts and techniques in a language.

There are a lot more - Scott Hanselman, Martin Fowler, Andrew Koenig, Andrei Alexandrescu, Barabara Moo and many more.
They remind me of why I chose programming. It wasn't for money or fame, just to solve puzzles in cool ways. It's the way you can take a simple concept and apply it to great effect that brings me joy and these people do it relentlessly.

To any Java developers. I been programming for about 2 years on and off. Im pretty good when given a task. But from your experience. What techniques, or methodologies should a Java programmer know of he wants to really get serious and get a job? Do you guys have portfolio projects?

I'm thinking about what language to dive into next.
I already have a pretty good knowledge of Go and mediocre knowledge of C and Java.

So far I thought about...
1. CPP, as I need it for school and it runs on literally anything.
2. Rust, as is seems to spread and the combination of low-level, memory-safety and abstraction seems pretty appealing to me.
3. Kotlin, specifically kotlin-native, is it combines java-like high-level programming with native speed.
4. Nim, as it combines high-level techniques with c-like freedom.

What do you people recommended, or something completely else?

React, it's declarative way of doing things, and the functional programming methodology it prefers.

Realized how much I've moved on from for-loops and class/object instance to maps, filters and immutability/observers when I worked on a Laravel project after so long and found myself forced to do things in the, erm, "PHP" way, despite spending my initial year and a half of programming working exclusively in PHP.

Sure, there's Class Components and imperative techniques in React but I had blissfully settled into using the flexible nature of doing things enabled by both native JS and React, with hooks, Lodash/Ramda and (almost fanatically) pure functions

Found a little magazine when I was 12 which talked about HTML.
Then later, a friend talked about VBS and VB.NET and I just started making prank shit in that...
Then later back to making websites and basically just grew from there really...

Only followed a formal education on programming once... Which I got kicked out off because I ended my first year with a splendid 2 (that 1 point for adequate attendance).
The fun part? I failed because I was too good :^)
All my grades where a 1 or a 2 because my code was made using tools and libraries that they didn't want me to touch or even know about until 3rd of 4th year...
So yea, I failed everything with the reason being: "Not according to the exercise".

Another fun part: We had to make a personal blog in the 1st year using the techniques we had learned.
Sites were published on a *public* server...
Someone hacked all sites... except mine :^)

A philosophical question about maintenance/updating.

There is no need to repeat the reasons we need to update our dependencies and our code. We know them/ especially regarding the security issues.
The real question is , "is that indicates a failure of automation"?

When i started thinking about code, and when also was a kid and saw all these sci fi universes with robots etc, the obvious thing was that you build an automation to do the job without having to work with it anymore. There is no meaning on automate something that need constant work above it.

When you have a car, you usually do not upgrade it all the time, you do some things of maintance (oil, tires) but it keeps your work on it in a logical amount.
A better example is the abacus, a calculating device which you know it works as it works.

A promise of functional programming is that because you are based on algebraic principles you do not have to worry so much about your code, you know it will doing the logical thing it supposed to do.
Unix philosophy made software that has been "updated" so little compared to all these modern apps.
Coding, because of its changeable nature is the first victim of the humans nature unsatisfying.

Modern software industry has so much of techniques and principles (solid, liquid, patterns, testing that that the air is air) and still needs so many developers to work on a project.
I know that you will blame the market needs (you cannot understand the need from the start, you have to do it agile) but i think that this is also a part of a problem .
Old devices evolved at much more slow pace. Radio was radio, and still a radio do its basic functionality the same war (the upgrades were only some memory functionalities like save your beloved frequencies and screen messages).

Although all answers are valid, i still feel, that we have failed. We have failed so much. The dream of being a programmer is to build something, bring you money or satisfaction, and you are bored so you build something completely new.

Once upon a time in the exciting world of web development, there was a talented yet somewhat clumsy web developer named Emily. Emily had a natural flair for coding and a deep passion for creating innovative websites. But, alas, there was a small caveat—Emily also had a knack for occasional mishaps.

One sunny morning, Emily arrived at the office feeling refreshed and ready to tackle a brand new project. The task at hand involved making some updates to a live website's database. Now, databases were like the brains of websites, storing all the precious information that kept them running smoothly. It was a delicate dance of tables, rows, and columns that demanded utmost care.

Determined to work efficiently, Emily delved headfirst into the project, fueled by a potent blend of coffee and enthusiasm. Fingers danced across the keyboard as lines of code flowed onto the screen like a digital symphony. Everything seemed to be going splendidly until...

Click

With an absentminded flick of the wrist, Emily unintentionally triggered a command that sent shivers down the spines of seasoned developers everywhere: DROP DATABASE production;.

A heavy silence fell over the office as the gravity of the situation dawned upon Emily. In the blink of an eye, the production database, containing all the valuable data of the live website, had been deleted. Panic began to bubble up, but instead of succumbing to despair, Emily's face contorted into a peculiar mix of terror and determination.

"Code red! Database emergency!" Emily exclaimed, wildly waving their arms as colleagues rushed to the scene. The office quickly transformed into a bustling hive of activity, with developers scrambling to find a solution.

Sarah, the leader of the IT team and a cool-headed veteran, stepped forward. She observed the chaos and immediately grasped the severity of the situation. A wry smile tugged at the corners of her mouth.

"Alright, folks, let's turn this catastrophe into a triumph!" Sarah declared, rallying the team around Emily. They formed a circle, with Emily now sporting an eye-catching pink cowboy hat—an eccentric colleague's lucky charm.

With newfound confidence akin to that of a comedic hero, Emily embraced their role and began spouting jokes, puns, and amusing anecdotes. Tension in the room slowly dissipated as the team realized that panicking wouldn't fix the issue.

Meanwhile, Sarah sprang into action, devising a plan to recover the lost database. They set up backup systems, executed data retrieval scripts, and even delved into the realm of advanced programming techniques that could be described as a hint of magic. The team worked tirelessly, fueled by both caffeine and the contagious laughter that filled the air.

As the hours ticked by, the team managed to reconstruct the production database, salvaging nearly all of the lost data. It was a small victory, but a victory nonetheless. And in the end, the mishap transformed into a wellspring of inside jokes and memes that permeated the office.

From that day forward, Emily became known as the "Database Destroyer," a moniker forever etched into the annals of office lore. Yet, what could have been a disastrous event instead became a moment of unity and resilience. The incident served as a reminder that mistakes are inevitable and that the best way to tackle them is with humor and teamwork.

And so, armed with a touch of silliness and an abundance of determination, Emily continued their journey in web development, spreading laughter and code throughout the digital realm.