[deleted]
Learning some functional programming. It really influenced the way I think about code and make coding desicions.
[deleted]
Submitted 1 year ago by GreyTechnician@lemm.ee to programming@programming.dev
Comments
404@lemmy.zip 1 year ago
dneaves@lemmy.world 1 year ago
Agreed. Functional languages really raised my standard for what a language could be.
Stronger typing. More functional flow. Less dumb errors.
Potatos_are_not_friends@lemmy.world 1 year ago
Reading code. Not just your primary language. But other languages too.
Most problems are already solved. Someone out there solved it. Maybe they didn’t solve it in the language you need. But fortunately, they provided their code on GitHub.
hperrin@lemmy.world 1 year ago
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.
otl@lemmy.sdf.org 1 year ago
This is a great trick that kept me going doing software dev professionally. Instead of trying to get the system I was working with to interact correctly with some shit enterprise system, I would find common protocols (or related protocols) and implement that well. Then I would discover more specifically where the shit enterprise system was behaving badly, and point to something politically neutral (like an IETF RFC) to help get us out of a rut.
It made debugging so much easier. Those specifications and open-source implementations have had much more engineering talent put in them than what I was usually dealing with.
Iapar@feddit.de 1 year ago
You seem knowledgeable, could you go a bit more into detail why you wouldn’t recommend activityPub?
Did you hear of nostr?
What protocol do you recommend and why?
If you don’t mind me asking.
hperrin@lemmy.world 1 year ago
ActivityPub was basically written to support everything any social network could do, so there aren’t really well defined ways to do anything. An example is that there’s no standard markup language for notes. They can be text, HTML, markdown, whatever. It was the first W3C spec I read through, and I’m used to reading IETF specs. Maybe I’m just not used to how W3C does things, but the spec left me with a lot of open questions. It’s ambiguous about how things work in a number of areas. Especially about what things are allowed in other things. There are parts where you get the impression that something can only be an array, but then later it’ll show an example where it’s a single item not inside an array.
It was also supposed to be both a server and client protocol, so that any server should be able to talk to any client, but they don’t cover at all how to actually authenticate the client to the server. Oauth is the standard, but there’s no standard way to add your client to any given ActivityPub server. So you just have to code for whatever server you want to talk to.
So essentially what I mean is that you can’t build functioning software just by reading the spec. You must look at existing implementations to see what they do before you have any hope of working with them. To me, that means ActivityPub is an incomplete spec. I hope they remedy that with an update.
I’ve heard of Nostr. It looks really great on paper, but in reality, it’s filled with spam and cryptobros. It’s not moderatable, which makes it a target for spam and scams.
I’d recommend something like SFTP or WebDAV. They’re incredibly well defined and very useful to have an implementation of your own. I’ve written my own WebDAV server called Nephele, and it was really fun once I got it communicating with other software. Now I use it on my own server and I back up all my computers to it.
A long time ago I wrote an XMPP client which was really fun. I wouldn’t say it’s as useful as the others because not many people are on it, but it’s a great protocol.
atheken@programming.dev 1 year ago
I would recommend email for this. It’s a text-based protocol and the original RFCs 821/822 are pretty straight-forward. There are some additional rabbit holes related to content encoding, but if one can implement a simple MTA, a huge amount of the magic of the internet becomes accessible.
I would not recommend trying to build a “production grade” MTA, as there is a lot of minutia to get right, and it’s easy to screw up.
NegativeLookBehind@kbin.social 1 year ago
“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.
bigbluealien@kbin.social 1 year ago
Stage 2, "why does this code have nothing to do with the very detailed comments?"
Traister101@lemmy.today 1 year ago
Always comment the why, not the what
NegativeLookBehind@kbin.social 1 year ago
git blameSavaran@lemmy.world 1 year ago
If the comments don’t match the code then someone failed to properly review it.
MajorHavoc@lemmy.world 1 year ago
Lol. That’s why we comment with “why”, rather than “what”. The answer to “what the duck where we even thinking?” usually doesn’t need updated until the commented code goes away.
Suppoze@beehaw.org 1 year ago
Never understood this argument, it’s the person’s responsibility who change the code to update the comments if needed. Otherwise they just implicitly admit that they did not read it and understand the context, or just plain does not care.
karlhungus@lemmy.ca 1 year ago
I hear this quite a bit, and think there’s actually a good deal of nuance to it. I’ve seen places that insisted on comments for everything, and it was silly, a significant number of comments had no value. This made people not read comments, as opposed to other places I’ve worked with very few comments - when you ran across a comment you gave it more weight (something here was complex, or not as simple as it seemed).
So imo, use comments which can communicate effectively, but use them sparingly for important parts that are complicated, for the rest attempt to communicate with the code itself.
robinm@programming.dev 1 year ago
step 1: learn to comment everything. This will helps code reviewer to catch errors because your code doesn’t match the comments step 2: write your code in a way that makes comments useless and stop writting them step 3: write your code just like you did in step 2, but documents all the things that you didn’t do, or why the code is more complicated than the naive approach. If your arguments are weak you are not in step 3, but in step 1.
s3rvant@kbin.social 1 year ago
Yep, was going to say that refactoring my own code taught me a lot
AnarchoSnowPlow@midwest.social 1 year ago
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)
bhamlin@lemmy.world 1 year ago
23 years in and I don’t think that there is better advice here. Listen. Practice. Experiment.
If it’s something you want to get good at, do it as a hobby. Pick projects that you don’t know entirely how to do. Adversity is a better teacher than anything else I’ve run into.
Learn other languages too. I learned more about C from a year of rust than two decades of C.
AnarchoSnowPlow@midwest.social 1 year ago
The only caution I’d add about doing it as a hobby too is that it’s super easy to burn yourself out. I think that’s why so many of us get into woodworking and gardening lol
jonwah@discuss.tchncs.de 1 year ago
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.
FourThirteen@lemmy.world 1 year ago
Test driven development has really helped me understand bugs and functional changes well. Doing a red green change has done wonders for me over the years.
TadoTheRustacean@programming.dev 1 year ago
Installing linux. If you are in a more comfortable environment you will be better at working
Lmaydev@programming.dev 1 year ago
I’ve found windows to be much simpler for many things.
Often the case of just installing an application from an installer.
And there’s WSL for when you want Linux.
JackbyDev@programming.dev 1 year ago
I don’t see how an installer is easier than typing a single command to get something from a package manager.
gornius@lemmy.world 1 year ago
If you’re a beginner:
I almost gave up programming once, I thought I was too stupid.
Then I learned Linux and figured out starting out in IDEs as a beginner is the worst thing you can do. It doesn’t teach you anything, it just lets you get the job done - the thing that you should avoid while learning.
If you can’t build your software with only CLI - you probably have no idea how technology you’re programming in works.
If you are intermediate:
Reinventing the wheel is a great way to learn how libraries you’re using actually work.
Knusper@feddit.de 1 year ago
- 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.
3h5Hne7t1K@lemmy.world 1 year ago
This is perfect advice.
abbadon420@lemm.ee 1 year ago
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.
hperrin@lemmy.world 1 year ago
Finding some project that I really enjoyed working on, and just absolutely going ham on it. That’s the best way to learn.
rebul@kbin.social 1 year ago
This is The Way.
tatterdemalion@programming.dev 1 year ago
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.
greenmarty@lemmy.world 1 year ago
For me this works best regardless of the field
- Learn basics
- then do this for rest of your carrier
,.-> Learn more ., .` `' ' \ | | . / ', ,- `'' Practise <-'`
Basically learn bit more -> use it immediately in any project - > rinse and repeat.
lysdexic@programming.dev 1 year ago
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.
314xel@lemmy.world 1 year ago
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 (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. Amd you get to use the latest frameworks / technologies which you might not at your workplace, depending on the company.
And last, contributions to 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.
philm@programming.dev 1 year ago
Yep this sums up my experience quite well too.
I want to emphasize two things here:
- Learn reading code (by reading code…) of high quality open source projects. It helps getting new concepts and actual creative coding patterns for concrete problems (unlike learning all these “design patterns” in books that IMHO are often just boilerplate generation (hard take I know…)).
- Start coding (open source) projects, especially challenging ones, and keep pushing your limits, by trying to learn new smart things, how to achieve problem X. I stagnated in my workplace for quite some time, got unhappy (around COVID), scaled down working hours significantly (I have quite a spartan life, so I can fortunately afford it), and am coding a lot more open source since then. I think I almost learned more in the last 2-3 years until at least to the years of university (quite some time ago), maybe even more than in university, and have a lot more fun while coding. I think going in depth with a programming language comes automatically, when the project is fancy enough, I learned a lot of limitations of Rust (and thus basically reached the deepest level of (parts of) the language) while designing smart APIs.
Waldowal@lemmy.world 1 year ago
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.
coloredgrayscale@programming.dev 1 year ago
Concepts still apply, so for a beginner an outdated book would still be a valuable source.
From there you can get up to date with the newest features with articles / tutorials. Cloud services probably should be first thing you develop for.
601error@lemmy.ca 1 year ago
Enjoying it, and time.
demesisx@infosec.pub 1 year ago
Learning that OO is inferior to FP for matters that are critical for safety.
Lmaydev@programming.dev 1 year ago
Can you explain that opinion a bit?
demesisx@infosec.pub 1 year ago
I could go on for a week but here’s some copypasta that mirrors why I wrote this (sorry not to write an essay in my own words). Honestly, there’s a lot more than listed here (like the inherent ability to parallelize any functional code basically out of the box) but let us take a stab at comparing them:
The functional programming paradigm was explicitly created to support a pure functional approach to problem solving. Functional programming is a form of declarative programming. In contrast, most mainstream languages, including object-oriented programming (OOP) languages such as C#, Visual Basic, C++, and Java, were designed to primarily support imperative (procedural) programming. With an imperative approach, a developer writes code that specifies the steps that the computer must take to accomplish the goal. This is sometimes referred to as algorithmic programming. In contrast, a functional approach involves composing the problem as a set of functions to be executed. You define carefully the input to each function, and what each function returns.
Advantages of pure functions
The primary reason to implement functional transformations as pure functions is that pure functions are composable: that is, self-contained and stateless. These characteristics bring a number of benefits, including the following:
-
Increased readability and maintainability. This is because each function is designed to accomplish a specific task given its arguments. The function doesn’t rely on any external state.
-
Easier reiterative development. Because the code is easier to refactor, changes to design are often easier to implement. For example, suppose you write a complicated transformation, and then realize that some code is repeated several times in the transformation. If you refactor through a pure method, you can call your pure method at will without worrying about side effects.
-
Easier testing and debugging. Because pure functions can more easily be tested in isolation, you can write test code that calls the pure function with typical values, valid edge cases, and invalid edge cases.
-
Pigeon@programming.dev 1 year ago
I often think about the learning pyramid and I find it lines up with my personal experiences.
The experiences which have made me better at programming are when I’m teaching others or when I’ve been working on projects in my spare time (practicing).
For example whilst I was still at university I decided to make a Discord chatbot and it really helped me build on what I’d already been taught.
Other than that I like reading coding standards documents, like this.
greenmarty@lemmy.world 1 year ago
I agree with pyramid. Teaching someone else or doing it was indeed the best practice indeed anytime i wanted to learn something better.
flamboyantkoala@programming.dev 1 year ago
-
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.
-
If I saw a new technology I thought would be useful I’d try it on my own before trying to incorporate at work.
-
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
-
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.
-
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.
-
jadedwench@lemmy.world 1 year 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.
olafurp@lemmy.world 1 year ago
Making a webapp for myself.
AlmightySnoo@lemmy.world 1 year ago
Reimplementing stuff from scratch, overengineering and, if you’re coding in a compiled language, knowing a bit of assembly to make performance-related decisions.
monsterpiece42@reddthat.com 1 year ago
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.
Kissaki@feddit.de 1 year ago
My personality, my curiosity, my hobbies exploring and doing
jack@monero.town 1 year ago
Find a program to work on and fix issues that interest you. Start small. It is satisfying to fulfill peoples feature requests, even if the feature isn’t helpful to you. You know that you made this person happy and there are probably more people who wanted that feature too
jadero@programming.dev 1 year ago
Going freelance. All the stuff I learned in formal and informal study and from those around me pales in comparison to what I learned from having to craft useful, affordable solutions for a wide variety of customers in several different fields.
It’s true that certain aspects of my technical knowledge took a hit, but creating line of business software solutions in direct collaboration with the actual end-users was a transformative experience.
One of the most important things I learned is that approximately nobody actually knows much about how to efficiently and effectively use a computer. About one third of my time was spent teaching people how to use computers.
idunnololz@lemmy.world 1 year ago
Writing a shit ton of code and doing it consistently over a long period of time with the mind set of trying to get better. You still need/prefer the other stuff people mentioned here like reading books and getting good code reviews, but there isn’t really a replacement to experience and some hard work.
kurosawaa@programming.dev 1 year ago
Read books. There are some great books on programming out there. I would strongly recommend a A Players Guide to C#. It’s structure, practice problems, and explainations of the basics were far better than any free guide to programming that I’ve seen online. There are a lot of other great books out there too.
It also doesn’t matter too much about a book being outdated when you are only studying the fundamentals.
A lot of the stuff you read online has never been fact checked or edited for clarity. Some of it is great, but most of it is not.
Prok@lemmy.world 1 year ago
Working with engineers that were better than I was and actually listening when they reviewed my code… Asking why and going from there.
AnarchoSnowPlow@midwest.social 1 year ago
“if you’re the smartest person in the room, you’re in the wrong room”
morphballganon@lemmy.world 1 year ago
Unless you’re giving a lecture
random8847@lemmy.world 1 year ago
Well, if every person thinks this way we will never have a stable room of people xD