Programming

Working with engineers that were better than I was and actually listening when they reviewed my code... Asking why and going from there.

Learning some functional programming. It really influenced the way I think about code and make coding desicions.

One thing that I found really fun and very educational was to find a protocol or format I found cool (something like XMPP, WebDAV, SSH, gzip, etc) and try to implement it in a place that wasn’t immediately obvious how (like, if you’re trying to learn Go, maybe don’t pick WebDAV, cause it’s already implemented in the standard library). I like to print out the RFCs or specs and put them in a binder. Then I read through and highlight important bits and put little sticky flags on the page. Then as I implement it, I’ll reference that printout.

It’s an incredible feeling when you get to the point that your software is talking to someone else’s software and it’s all working. And it really teaches you how the software you use every day really works under the hood.

Btw, I wouldn’t recommend the ActivityPub protocol. Even though it’s really useful and really powerful, I don’t consider it to be written very well or novice friendly. There are a lot of places where it is either ambiguous or just flat out contradicts itself. If you find a protocol like that, it can make you want to pull your hair out.

“I don’t need to comment this code, I wrote it so I know what it does”

And then

“Fuck, I should’ve commented this code, I have no idea what it does”

Comment. A lot.

The short answer is "practice"

The longer answer is, do it a lot. Listen in code reviews. When you investigate bugs, do actual root cause analysis, understand the problem, and understand how it got missed. Don't stop learning, study your languages, study design patterns, be intentional in what you learn.

I had good mentors that were hard on me in reviews. Developing a thick skin and separating criticism of you from criticism of your code will help a lot in terms of learning in reviews.

Source: 10 years in the field. (Senior SW Eng. Focused on embedded systems and VnV)

When I had to fix a bug, I made sure not to just fix the problem, but to understand it.

There's a massive difference between the two. When I was a junior I would often find out how to fix a problem by googling and trying different things until something worked, but I wouldn't understand why.

Then I started digging into what was actually going on under the hood and finding out the why of things - sometimes it was to do with a framework, sometimes a language, sometimes it reveals a fault in yours or someone else's programming.

But every single time you learn something new and it solidifies your knowledge of your tech stack and programming in general.

Also, one of the best phrases I've ever heard in programming is "every bug is a missing test" - these days the first thing I do with a bug is write a test to expose the bad behaviour - then you can go about fixing it with confidence and preventing regression errors.

Installing linux. If you are in a more comfortable environment you will be better at working

• Learning multiple programming languages. Each one gives you a glimpse into the problems that some very experienced devs thought were worth solving neatly.
• Switching to Linux. The whole OS wants to teach you about its innards all the time. You can actually debug problems in software you use. And you can script all kinds of things or even start contributing to basically any application. It's just really good at teaching and motivating programming.
• Explaining things to others. It's quite easy to have just superficial knowledge in tons of topics. And sometimes, we don't notice, even if it's something we do every day. Try to explain to a noob what Git is and you'll likely struggle, both with the meta description and detail questions. If you then read up on the concepts you couldn't explain, that will give you a much more complete image of Git and ultimately help you whenever Git becomes more complex.

Finding some project that I really enjoyed working on, and just absolutely going ham on it. That’s the best way to learn.

Teaching. I work for a university now (I have zero work experience), but you can also just make youtube vids nobody'll ever see. Explaining how a concept works requires you to have such a deep level of understanding that you'll find it impossible to properly do wothout learning more about it. In the end you'll teach yourself more than you teach your students.

My take: actual, hands-on programming is way more rewarding than reading and watching tutorials.

I learned a lot at work (80% still self-tought, rest from interaction with other teams and other people better than me and with greater experience), and it usually came from needing to make my job easier, not to please the clients or management (scripting and automating things, Linux, DevOps, etc).

The other part through personal projects (again, out of need). You need to take on a project with real use to you. And you get to use the latest frameworks / technologies which you might not at your workplace, depending on the company. Working on personal projects will give you a different kind of fulfillment and will keep you remember that you love to code. Work is work, play is play.

And last, contributions to public, open-source projects. You need to read and understand other people's code, get familiar with Github, write clean, documented code and respect the standards for the project. It will help you in the long run, and you could also add something to your CV.

As for the actual things to learn, don't get stuck on learning just the framework, which does a lot for you out of the box by running commands or calling packages. Try to go in-depth in a programming language and play with the bare-bones, learn the intricacies. Learn for example how code runs and where. I have colleagues still thinking that queues are magical and asynchronous, they write a few lines of code and just work when deployed, without any actual knowledge of the architecture of the system they run on, this leading to no thought in optimization and speed of their code. Or they use the ORM exclusively, which, again, doesn't help when shit hits the fan and you need to debug and optimize for bulk processing.

Also, learn a bit about cryptography and cyber security, even if only for yourself as a hobby. This is where I see a lot of developers lacking, to the point that most don't know the difference between hashing and encryption. There is no project nowdays in the universe where security doesn't matter.

The difference between a mediocre programmer and a good one might not be obvious during an interview, but they will show during the trial period.

For me this works best regardless of the field

1. Learn basics
2. then do this for rest of your carrier

                             
     ,.-> Learn more .,      
   .`                  `'    
  '                      \   
 |                        |  
  .                      /   
   ',                  ,-    
     `'' Practise   -'`     

Basically learn bit more -> use it immediately in any project - > rinse and repeat.

What really helped me get better as a software engineer was going out of my way to progressively learn as many software design patterns as I could and iterate over pet projects to refactor them to apply them in practice. It helped me write cleaner code that's far easier to maintain and extend, it helped me be far more efficient at onboarding onto projects, it helped me greatly improve my skills as a software architect.

Do challenging projects. Read code from better engineers. Work with better engineers. Try new languages that actually solve technical problems instead of just having nice syntax. Contribute to open source projects that you use. Actually read the manuals that come with your tools. Notice when it's taking you a long time to do something and reflect on it to find a faster way. Constantly tweak your workflow to be more productive.

And the most important of all:

Get a split ergomech keyboard.

It's fallen out of popularity over the years, but reading programming books. The big ones. There is an expectation that a book will contain every bit of info about a technology, and you can learn it, in depth, in one place. Online articles, videos, etc., often just skim the surface. You don't get that deep learning and facts that the books would have. I find even "Official documentation" online is sparse and often doesn't include examples to gain understanding.

Unfortunately, the pace of change, especially in cloud services, cause books to be out of date too quickly, so I don't see it making a comeback.

1. Once I felt like I had mastered a language I’d start learning another. The techniques in a new language would teach me things to take back to my primary language. Functional Programming for instance was great at teaching the value of simple functions. Prior to that I’d put everything in Objects which had implicit state leading to sometimes hard to reason about code. Also Objects still have a place for making easy to reason about code.

2. If I saw a new technology I thought would be useful I’d try it on my own before trying to incorporate at work.

3. Downtime at work was used to learn more programming by working on projects that would help make my life easier at work. Bash scripts, improved builds, improved developer tooling

4. In the corporate world. Learn the soft skills, when to talk when to be quiet. How to brag about your work appropriatly to get those raises.

5. Constant learning. Programming changes fast. If I stuck to what I started with my skills would be far out of date and my job selections would be slim.

Enjoying it, and time.

Making a webapp for myself.

Practice! Frequently take on tasks that are above your skill level and then learn to do them while you're doing them.

Learning that Imperatuve Programming is inferior to Functional Programming for matters that are critical for safety.

I think of it in terms of levels building on top of each other, or circles enveloping each other; also how I evaluate interviewees and new hires:

1. Finishes the task, but needs handholding
2. Finishes the task, figuring it out from docs, guides, and internet
3. Finishes the task, proactively trying to make sure it doesn't return again as a bug or failing QA
4. Finishes the task, designing things in a way so that devs don't need to put in extra effort in the future

In short, learning how to do something right, but also alternative strategies, how to pick the best option, and finally make sure you always end up with the right choice, or automatically do so, by design.

It's at core a matter of experience, but taking on new opportunities and reading up helps to accelerate that.

Reimplementing stuff from scratch, overengineering and, if you're coding in a compiled language, knowing a bit of assembly to be able to make better performance-related decisions.

EDIT to clarify the overengineering part: the idea is not to do it at work obviously because there you will have to meet deadlines and you will have to spend time on what's most important, but the idea instead is to do that when working on your own personal projects. Try to make every component of your project as "perfect" as possible as if you were trying to rebuild a Mercedes-AMG car. That's how you'll learn a bunch of new tricks.

A) Practice.

B) Interacting with programmers other than yourself.

On a more specific note:

• Don't work "around" problems. Identify what the problem actually IS and work backwards. When you try to take a step and find that you don't know what step to take, or you're stepping into something you don't understand, go research and learn about it.

• Learning how to read technical documentation is a valuable skill.

• Recognize and challenge your assumptions. Which plays into working "around" problems. Do I know the error I'm researching came from this bit of code? Is this bit of code even running? Is the source file I'm looking at even part of the binary I'm running? Is the binary that's running actually the one I'm trying to test?

I'm a new programming student and the single best thing I have done is just start trying to do projects. Sure I have VS Code or Eclipse in one window and maybe Stack Overflow or chatgpt in the other but I slog through it and it has been for more helpful than all the reading and tutorials.. I've learned far more. I wish I had started this years ago.

For the love of all that is unholy, learn and get comfortable with the command line. Go install WSL if you are on Windows. Not saying you have to be a master, but learn how to compile your code manually, get around the OS, tab complete, grep, ps, and other simple commands. Learn the basics of a text editor. vim/emacs/nano. Just pick one or two. Learn how to redirect output to standard and error out. Simple shell scripts.

Debugger. If you do not know how to set breakpoints, with or without conditions, and inspect variables, go learn today. I have junior developers that can't do this.

Critical thinking and investigation. This is a rather loaded term, but your problem solving skills will go a lot farther than how your code looks. Bad but working code can be improved. Alternative solutions can be found. You at least understand the problem and an approach to take. If you don't understand how something works, figure it out. Ask your senior team members. Spend time in the debugger and the source code, if available. Good documentation doesn't always exist. You will not always find the perfect answer or tutorial on the Internet. If you are going to use code off the internet, you damn well better understand how it works and how to expand on it.

Keep up with the standards and updates to the languages you use. A lot of tutorials can be out of date fairly quickly. Newer language features can be a huge boon and you get a sense of where that language is going. Older ways of using libraries and languages can be hard to avoid, but make an effort to check. Speak up to your seniors if you find something that may be useful or if something is now considered bad practice.

Look at source code on GitHub/GitLab/Whatever and then the all mighty practice.

In my opinion, once you can get a handle on the above, then you can go back and learn more advanced principles, algorithms, read textbooks, and things like that. They will make a lot more sense. This may seem a little opposite than what most people would say, but for me a lot of the things I learned in school or read previously started to click.

Making my own software and challenging myself to solve problems. I'm currently working on a TUI frontend for Lemmy because I don't really like neonmodem.

Nothing. I'm still shit at everything as always.

Learning how to read documentation

I generally say, "I want to make X" then I slowly work up to it. Currently I'm making a pathfinding algorithm.

I input a map with my starting point and finishing point and it has to get there. It has to know where to go back to if it goes the wrong way, when it's allowed to stop, etc.

The next steps will be getting it to only show the finished path, then to work out the fastest path when it has multiple possible paths etc.

1. Learn coding from YouTube videos/books/etc whatever you prefer

2. Break the information you learn down into small, applicable chunks. For example: How do you add heading in HTML? Use tag.

3. Write that information down. Handwrite it, don't type it. This is because handwriting things helps you memorize it a lot better. Focus on what you write and try to understand what its doing and why it was designed that way.

4. Use the information in small projects, using the stuff you wrote as a reference. Those small projects can be like "simple python script that uses a for loop to print text", aka simple things you don't release to the public and solely exist for practice

5. Revisit the stuff you learned after a couple days aka try making the same projects again or a new project that uses the same concepts.

Using this pattern I've been able to learn things much faster than most others. It's based on a lot of tricks people use for memorize things better, such as writing things down and spaced repetition.