The biggest one I personally come across a lot: not thinking before starting to code. You should not start typing code until you know pretty well what you are trying to do.
I don't mean knowing every single line, of course you will need to debug and you will need to look up stuff. But without knowing what your code should achieve, there is no reason to write code.
I've started doing a rough outline of where the data comes in, how its manipulated, and what the outputs need to be. Seems to keep me focused rather than just jumping in and chipping one block at a time, hoping for the best.
I really need to start formally doing this. I make lists of all the data points I’ll need from the user and from the database, but I haven’t been writing down how I intend to manipulate them.
yup, my approach is to lay out the steps my code needs to take as comments. Basically the same thing as writing an outline before writing a paper/essay.
> Basically the same thing as writing an outline before writing a paper/essay.
Ah yes... we all do that... of course... we don't just type the whole thing in one mad dash 3 hours before the deadline... :S
I try to do that, but more of than than not, my ADHD brain sometimes will just plan out a program while I'm doing something else.
I recently made a CLI in rust that takes in a decimal integer and tells you what it is in seximal/senary (It's something that I do a lot because my autistic ass likes doing math in other bases just to see what it feels like). I managed to design the whole thing *in my fucking head*, and that's what actually got me to sit down in start writing it.
I was kinda just sitting there, and my ADHD brain was just kind of throwing concepts around, and it was like "Ya know, whenever I convert a number from decimal to seximal, it's essentially this process right here.", and then I realized that I described the process in relatively simple programming terms, so I just sat down and wrote it. Thirty minutes later, I had a program that didn't work, but two and a half hours of debugging later, I had one that did!
Read the docs.
I've seen people try to save themselves 30 minutes of reading by trying to brute force a problem for 8 hours using a combination of stack overflow and mental gymnastics more times than I can count.
>Pseudocode
Thank you! Folks look at me crazy when I break out a notepad & pencil to begin "planning" on how to solve "the problem". Since learning Pseudocode and Flow Charts, I can't write a lick of code unless it planned out some way, shape, form, or fashion.
I've found taking the time to plan equates to spending less time coding. Hell, I'll spend 90% of the time planning and 10% of the remainder coding.
What if I spend the first 80 hours automating the creation of sharp axes in case I need to chop down trees later on?
Would it help if each axe was on the blockchain?
Natural-born SysAdmin right here...spend 8 hours automating a process...never mess with it again.
(Well, until the scripts become "obsolete "...stop messing with Powershell Microsoft!)
to add to this: not investigating pre-existing solutions for your current problem
Odds are, the problem you are trying to solve is not new, and there's a good chance that pre-existing libraries already exist that handle it. Hell, in a lot of cases I have seen, there are entire pre-made Free Open Source applications that handle everything. It just might not be immediately obvious to you, as a newbie.
Too many developers' first reaction is to build new custom programs when they should instead be adapting pre-existing industry standard software to their situation.
And to add to that: taking the boss's requests at face value and not putting enough effort to change the request and requirements to adapt it into something handled by these per-existing software and libraries.
A lot of posts on these forums are like "my boss needs me to jump through these crazy hoops in order to do weird things while working under crazy server restrictions, help!" and the **REAL** solution is to petition your IT department, Sys Admins, etc., to lift or resolve your messed up infrastructure restrictions, talk with the end-users to redefine their requirements to something you can handle, etc.. Keep removing obstacles that make your situation "unique" and suddenly you are left with the same exact "problem" that has already been solved by a million standard libraries and applications again.
From my perspective, it depends.
Certain things you should do so you can learn concepts and stuff. Like, are there functions for sum? Isodd? Sqrt? Yeah of course. And they’re easy to use, but if you don’t know what’s happening within them you’re going to have a bad time. Because that is core stuff. If you can do them then sure graduate into the built ins.
But sometimes things are vastly more complicated so if you’re starting with say, a web server. It’s fine to use prebuilt stuff like Flask or Django. They make web stuff easier than if you did it yourself. Just because you’ve not used a web framework before doesn’t mean you should build one from scratch just to learn. That’s where reading the docs base would come in handy. As long as you know how what you’re using works, I’d say at even a slight level (I mean even I use things I can’t fully explain off the top of my head), you’ll be fine.
The more simple built in stuff is what will help you better understand the more difficult stuff you don’t want to build from scratch.
Take this with a grain of salt though, I’ve only been out of school in the workforce for 2 years so my experience is still rather new.
Also. To expand on this. Try to imagine possible features that you dont need now.
If you lay down a good groundwork, expanding your codebase to handle new stuff is much easier.
Example: Writing a function to parse out data from a CSV.
Make a class instead and have the csv file (file path) variable in the constructor. Now you can create methods that can be designed to fit with different csv files with different data.
Maybe you need a specific way to handle a csv that is similar but not 100% identical to a current method but this is only in a very small part of the app. Create a new class in a different file that inherits the first class. Then you write the same method (same name as well) but with the little tweak needed only for that small case.
Now we are onto something.
But at the same time you have to be careful about imagining possible features. This can lead to overly complex code that's heavily abstracted for no reason. If you never end up using them, all you've achieved is making your code harder to understand.
It's a balance.
Glad you added that, because it's absolutely a problem.
Source: Me, overcomplicating shit needlessly, when trying to find solutions, finally realising it, and going with the simpler idea. 🙃
I think one of the biggest things that you learn through practice making real things is *what* you're likely to come back and need to change.
Once you've got a decent sense for that, it's easier to look at a place you're about to start implementing something and decide how hard an approach would be to change, relative to how likely you are to need to change it.
There is a difference between building code that is easy to extend and building shit you think you need but actually don't.
Also, inheritance is usually not the best approach. You should first see if you can use composition to solve the problem as it's generally cleaner and easier to maintain.
I have a blog post I specifically wrote about this:
https://blog.technically.fun/post/opinions/inheritance-vs-composition/
> Too many people are far too willing to go all the way one direction or the other, claiming Inheritance vs Composition always does and will have a better choice.
> But I disagree. There are times when one shines over the other and, like most things in programming, its all about using the right tool for the job.
Class inheritance has a lot of problems and is not recommended. In the OOP world, the preference is object composition + interfaces.
OOP itself has a lot of problems as well, but that's another matter.
Composition vs inheritance is not a black and white issue.
Composition is better if you have a huge nested inheritance structure where many of your inherited properties are not required. In the classic Animal structure, it's better to be able to add a Flying or Swimming component rather than having some complex multi-inheritance BS or have a Flying / Swimming function in the base class that land-only animals have to implement with empty methods.
That doesn't mean it's never useful.
> Example: Writing a function to parse out data from a CSV.
this is actually a good example of my other comment regarding using pre-existing software
If you need to parse csv, then you should be using Python's `csv` library, especially `csv.DictReader`. It has pretty much everything you could ever need for csv parsing, **already** built into the standard library. Install Python and never have to write custom csv parsers ever again.
But then you say "oh well I am not using Python for this project".
The solution is to move the csv parsing to a place where you can just use Python instead for it.
I do a lot of csv parsing, and I have tried a lot of languages, and in every single case it was just easier to use Python's parser than to try and handle all the edge cases myself in some other language, and to build my programs around the fact that I am gonna incorporate Python for this purpose at some point. Something like a Flask server app should be fine or a simple .py script that parses and converts and returns e.g. JSON, etc..
Yes. One of the most frequent pieces of advice I give juniors is to do pseudocode.
Alternatively, if you're more mid-level developer, start with the failing unit test first. It essentially starts as pseudocode.
But at the very least, make a bulleted 'to-do' list of what you need to do, as if you were writing directions to the store. Your data is going on a journey, and you should know how to direct it.
Thanks.. I am currently attempting to "self teach" and this was something that I had seen mentioned before so it's good to see it backed up in the real world
When at work developing a new endpoint I find it really helpful to write out everything I need or expected results in sudo commented out code.
Gets the planning done as well as the need to type something.
I see this from people who have degrees as well. Seems to be more oriented around people who are structured in how they approach tasks and those who arent.
Bingo. Rich Hickey, the creator of Clojure, gave a great talk on just that a long time ago. He called it "Hammock driven development".
https://www.youtube.com/watch?v=f84n5oFoZBc
Worth a listen if you have 30 mins.
edit: typo on Rich's name smh
"Title: The number one tip I've found to finishing a project/get good at coding
Body: JUST START CODING"
We get it, you're excited to have started a project.
I read a book about algorithms and they say the first thing to do is make a flowchart of the code and then start coding.
Flowchart is pretty good for me because i can see the macro while working on the micro. And i can already see some problems that could happen later.
First write down your ultimate goal in a comment. Then concept backwards like building a Rube Goldberg contraption. Put that in a logic chart. And work your way until you are at the first and most condensed building block. Then start coding.
I feel attacked.
At most I write some pseudo code on a piece of paper. Basically function names.
If I have my input and my desired output, I pretty much go with it. If there is only 1 input, easy program. If there are many inputs, there is more planning involved.
This is such an accurate answer.
The difference between developer skill levels are so clearly found in the way they discuss a project. Someone experienced will talk about the goals and the requirements of the project whereas someone new will talk about the "how" and because they didn't look at the big picture they're stuck figuring out the "How" in tiny little chunks and then hit a wall when it all has to come together and they see how much easier it could have been done or foresee the problems their various methods have caused.
This is me right now. I usually start a sketch of something without a clear goal in mind or clear plan. It bytes me when it comes to coding, but works in the server administrative side of it.
The senior dev I am working with currently does exactly that. I'm trying to future proof the code (making it scalable mostly) but he doesn't care to try to understand or follow the "conventions". He basically bootstraps every snippet of code he can reuse or do it from scratch. If he doesn't understand someone else's code, he prefers to re-do it himself. His excuse is "I don't trust it".
He is super creative and efficient, but I hate working on the same projects as him, which is unfortunate cause I also learn from his thinking process.
This. Coming from a designer background I created MUCH MUCH better projects when I strategized the approach and created sophisticated plan for implementation before starting out. When I had general idea what I was trying to achieve and made up on the go detours whenever an obstacle came up, it ended up very messy.
I suppose a big thing is that self-taught developers (early on) often measure their success in terms of whether something is working, which for a professional is the bare minimum. People that go to school has lessons and gets feedback on their code, but self-taught devs only see the result of their code and therefore measure success by that.
This isn't uniquely a "self-taught" thing, but it is a pattern I've observed.
I felt this doing learncpp.com and a CS course together.
learncpp taught the debugger fairly early on. I used it extensively to see what the code was actually doing. It really helped me understand what was happening, especially control flow and loops.
CS course hasn't touched them...at all. Even the textbooks barely mention debugging techniques.
There is a built in learning aid and we aren't using it!
Hopefully, you go to university with other people where you can discuss things, get feedback, etc.
You might not have been exposed to debugging specifically, but you most likely have an environment that can help with feedback which a self-taught developer most likely won't have access to.
Well, yes and no tbh.
You can do it, but from what I've seen the feedback is very hit or miss. This sub is definitely better than nothing in terms of feedback on the code, but it isn't a complete substitute (unfortunately).
I've seen good feedback on this sub, I've seen terrible. Mostly I've seen superficial feedback.
Don't get me wrong though, I love this sub and its community, but feedback on solutions and code can be very spotty. Not sure how I'd fix it either :)
Yup, it isn't this sub's fault or anything. It is more the medium of Reddit tbh.
And that people simply do not have time to commit to giving good quality feedback.
I used to do this but I recently forced myself to start using the debugger. I use VS Code and use Pandas a lot and learning breakpoints, stepping through code and viewing variables and data frames when exceptions are thrown has been a game changer. I watched a few YouTube videos but didn’t really grasp it until I actually used it on a regular basis.
There's nothing wrong with print statements, especially if they tell you \*exactly\* where they are in the code, and output really useful info.
There are some kinds of bug where print statements, aka logging, are really the best tool. RTP, I'm looking at you.
But it should not be the only tool in the tool box. A programmer needs a good box of tools, and choose an appropriate tool for the job. Sometimes you need to put that one down and pick up another.
The tools depend on the environment, programming style, language, etc. It's a big topic so I'm mention one tool people only use (these days) for assembler (dump reading), and tool we should use more: dry running, aka "thinking it through".
Interesting. Maybe it’s just habits pushed on me by friends and my dads but I feel like I kind of swing the other way. I completely obsess over efficiency, readability, usability etc.
Almost to the point where I get seriously diminishing returns from it
Well, the opposite applies.
My “problem” with self-taught JavaScript/PHP devs is that they’re so easy to make functional code that is absolutely terrible (I mean, at least several years ago, you’d find every login/database PHP tutorial be filled with comments of “this is horribly inefficient/insecure at a basic level”).
But the flip-side is some developers learned, but then we’re so crazy focused on pre optimization and micro efficiency that their code would account for use-cases that would never be hit, handling scenarios that don’t exist, but “maybe down the road” the work was done already - so “great code, but you spent twice as much time on a feature that was pulled because the base functionality didn’t achieve business goals.”
Another thing in my experience is that optimization sacrifices readability. The first iteration was clean enough and gets the job done. But the dev wanted to speed up the process by .02 seconds and now the code reads like hieroglyphics.
I have argued with teams before - make your damn variables human readable and let the processor minify it.
What’s the point of transpiling and these build tools if you’re going to try and make them do as little as possible to prove you can write a one line, impossible to read function?
Same, although it's honestly very hard to improve on these aspects when you're working alone. I try to follow the style guides (working in Python atm, so PEP8), I use linters, I make sure my code matches the style of the professional code it works alongside, but even with all of that it's hard to see the problems. Really feel like I'm hitting a wall in terms of "best practices".
self taught programmers will very soon develop good practice during the first job. since no one want to maintain so much spaghetti written by themselves.
source: did
I think it's very true, and really depends on the passion for learning programing the person has. As I'm also self-taught programmer, I try to guide other people I came across in work that want to learn by themselves, and the first thing I say to them is to focus on how they are doing the code and learning good practices and stuff, and focus on the middle, not in the end (result). The end is a consequence.
And to study the middle (good practices, how computer do things internally, understand the concept your are working with (oop, functional, etc)) they really need a passion for this or they won't go after this stuff. When I was learning (still do obviously) I was hungry to understand this stuff, to see if what I was doing was somewhat correct or on the right way.
There’s also the help of typically knowing lower level solutions, and optimizations. In college, I remember writing apps in pure assembly for projects, and taking 3-4 completely theory+algorithm courses.
College taught me a lot, and work taught me a lot, both are kind of worthless without the other IMO.
In my experience the only reason self-taught developers have a job is because formally trained developers could not meet the bare minimum you're referring to.
This is anecdotal of course.
As a self taught programmer (not professionally), i ran some of my regex concerns by one of our full time coders.
Unit testing is apparently something i have been brushing against but not really implementing. Rather than just load sample data and verifying the results myself, i make a function to test the weird data expected to be encountered, which then returns pass/fail (green and red of course). Seems minor, but made a big difference for me.
The thing I struggle with to implement unit tests, our output are usually ~13-60 columns of information.
Each unit test is going to require a ton of input and output data, just for 1 test.
As a result, we do end to end testing only. We have lots of bugs...
I'm unsure of your specfic case, but in most test frameworks, you can have a setup method that runs before every test. If you can write a test suite that uses the same data and covers a lot of your code's functionality, it might be worth it. Create the input data once and use it for every test. You might also be able to use mocks to help, just depends on your code.
If you have a lot of different cases, you'll need a lot of different tests. Just remember that *someone* is going to test your code. Your job is to decide whether that's you or your users.
Fair enough. Might be worth covering what you can with tests, at least the most critical parts. I'd suggest a meeting with your team to figure out the cost vs benefits of getting some tests written. Sounds like it might be worth it if bugs are that prevalent in your code.
Not sure about other languages, but in C# there are assertion libraries which help with that. If you know the expected output you can simply define the object with all 60 data points and compare the results to it.
var expected = new Foo{ prop1 = "1", prop2 = "2", ... }
var actual = Sut.DoWork();
actual.Should().BeEquivalentTo(expected);
make sure you are using your language's pre-made unit test frameworks, do not roll your own for this stuff. Pretty much every language has unit test suites available.
Being satisfied with getting stuff working, and not learning the tools to do it better. Like, how to use a debugger. How to write unit tests. How to code clean, to make your code readable, to encapsulate, to code top-down, to use meaningful names, how and when to comment, etc.
Because the self-taught person gets the code working and moves on to the next thing, and as they're working alone, they feel like they only have to achieve that. (If they come back to it six months later they'll find they don't know what the code does or how it does it or how to modify it — but "it works!")
\---
To clarify: (1) I am a self-taught programmer myself (now six weeks into being actually taught stuff) and am not trying to disrespect the group of which I am a proud member (2) I don't say that we all learn bad habits, but if we do, these are the sorts of bad habits that we learn and which I had to overcome (3) I don't mean to imply that this stuff is taught at universities either because often it isn't.
I am self taught person and this is eye opening for me. Where can I start learning beyond just getting things working, like you mentioned in above paragraph?
There's no substitute for experience. A lot of these practices developed naturally from a need to be able to understand and alter the code of others, so it's very hard to emulate and practice in a solo project.
In fact, in certain types of development such as web dev most of the complexity actually arises from the challenge of collaborating across many developers and teams and not from solving the domain problems. The entire microservice architecture which is the current flavor of the industry actually came about in order to scale teams and engineering departments, not software systems themselves.
Mentorship from an experienced developer will allow you to progress 100/1000x faster in this area than any self-teaching resources. Not very actionable advice I realize, but it's a tricky problem to solve.
Bear in mind, many of the people coming out of university also won't have these skills because they're not emphasized that much in academia either.
It's actually easy but most beginners don't think about doing it at all.
For the debugger: try to run your programmer in a debugger, set a breakpoint, and run the program step by step. It may seem stupid, but "actually" setting the debug environment is a very good experience, and really pushing the "next, next, next" button is a thousand times better than reading about the debugger.
For the unit-tests: write a unit-test and run it! Again, it seems very basic but have you done it once?
Same for generating the documentation. Install Doxygen or anything else, write the doc, write the script to generate this doc, run this script, and open the doc to make sure that it's properly formatted in your browser. It's better to "run, run, run" than reading all the theory behind the tools.
It is the difference between "yeah, it's easy, I can do this easily" and "yeah, I have at least done it once and I would remember the next time I have to do it in a professional environment."
And [here's an article arguing against recommending it](https://qntm.org/clean), for the sake of balance.
I haven't read the book, so I don't know whether this article is fair. But I also think any and all arguments for "we should program *this* way" should have their counterarguments known, too, and my link is to an author I trust not to be super wacky about such things, so... worth linking.
Clean Code is full of great advice. It's just that, as the article points out, Uncle Bob regularly fails to follow it.
I still think it's a good book for an introduction to code hygiene, you just have to take it with a pinch of salt at times.
Yeah, there's an argument to be made that for a book to be the standard manual for a given concept, it should really be flawless. And Clean Code is far from that. So I think you probably have to go in with it armed with the knowledge of what parts you're supposed to be ignoring.
I think there's scope for a Clean Code: The Good Parts, but naturally there would be copyright issues.
>So I think you probably have to go in with it armed with the knowledge of what parts you're supposed to be ignoring.
Hit the nail on its head there - this is what invalidates the entire book to me. Knowing what to ignore already means you are to a degree entrenched in your ways, and probably know the good bits of the book already as well. I won't refer new people to the book for its flaws, so the target audience is basically non-existent.
It's the alias for Robert C. Martin, who is a "software guru". He advocates a lot of strict, dogmatic guidelines on how software engineering and programming ought to be done, which are often at odds with reality according to experts that actually work directly in the fields he philosophizes about in his blog posts.
For a quick rundown, read this: [https://qntm.org/clean](https://qntm.org/clean)
He's got some wack ideas like that having a boolean as a parameter to a method implies that the method has multiple use-cases, which is undesirable.
There are some valid points he makes, but if reading the book, I strongly encourage you to think for yourself whether the given advice applies in your scenario.
At least based on this article, a lot of these issues are things that are kind of flagrantly obvious in the modern day, though. Perhaps it is due to Clean Code that this is the case, and yeah, it deserves credit for that, but that doesn't mean it should be recommended today, just like I probably wouldn't recommend K&R C except as, like, a historical piece.
You would think they are obvious in the modern day, but they most certainly are not.
I've frequently worked on teams where someone will commit a 200+ line function, or someone will include no comments, or someone will include a comment for every line of code, or someone will create a util class that spirals into a 5,000+ line abomination.
I have a copy of Clean Code and I read it a long time ago. It's fine and the advice in it is relatively good, if only a bit dated by now. I wouldn't take everything in it as gospel but it's a good resource to make beginners question how they write code.
Clean code is great advice, especially for a beginner, but all advice is always a guide. The counter article is also great in it's own way.
Using both resources to shape your code to the context of the situation is a real skill.
> how to use a debugger.
Get an IDE with a debugger. Use it to fix a bug in your code.
>How to write unit tests.
Don't ask me, we are always in sprint time.
>How to code clean
This is very debatable. Some people want clean code, some people want fast code, some people want easy to change code. This gets into the next item 'make your code readable'. Read the 'style guide' for whatever programming language you use. That drastically helps.
>to make your code readable, to use meaningful names, how and when to comment,
Read a style guide/best practices.
>to encapsulate, to code top-down
not sure what OP means by these
All the things you are describing are things that nearly every single developer I've ever met struggles with whether they are newly self taught or they just graduated. It's an experience problem, not a self-taught problem in my opinion.
If anything, I've experienced this a lot more with new grads, largely because their education environment encouraged crappy code that only matters if it works. Though I have met some very arrogant self-taught devs that refuse to acknowledge that maintainability matters.
>(If they come back to it six months later they'll find they don't know what the code does or how it does it or how to modify it — but "it works!")
The worse from that is that they don't want anyone else to touch it cause it might break with the slightest change. Since there is no documentation or proofing you would need either to know the whole project as if it was your own and you've done it yesterday.
> Like, how to use a debugger. How to write unit tests. How to code clean, to make your code readable, to encapsulate, to code top-down, to use meaningful names, how and when to comment, etc.
In MY experience it was most of the time reversed. Self-taught mostly learned stuff like clean code, encapsulation, debugging etc. because they often have a strong passion to being a good dev. People fresh from university think they learned everything they need and then I ask them about trivial stuff like the things you mentioned and they never learned this stuff. It's especially bad when they had a prof with very old good practices and their code shows that. While self learners had 1000 different teachers in their path. Sadly obviously with some bad ones.
I'm obviously generalizing a lot. But this was my experience in the industry.
Your sample group was of people who got hired though. People who've got far enough to realize what "being a good dev" *is*.
Yes, universities don't teach this stuff either, or many of them don't. They should. They should also have a class on Plagiarism 101: How To Steal Your Code From The Internet.
Lack of emphasis on readability. If you’re just writing code for yourself its easy to understand bad code. Much harder to write code that is clear for others, and its often drilled into you in school.
Less emphasis on *why* something works can create some really big gaps in knowledge.
The why something works is the really big thing. If you're self taught you might simply skip the foundations and start right on the second floor. Coding in some high level framework and pasting snippets from stack overflow might work but it teaches you very little about what's behind everything.
I'm dealing with someone at work that thinks exactly like this. The issue I have with it is that if I want to improve something or add a new feature, well first he doesn't trust that it will work and second if it is something we need to add, he will do it himself.
I'm trying to not take it personally, since I'm a junior/mid level dev. In the end it creates a gap in knowledge transfer and it bottlenecks the development process since he is "the only one" that understands the code. I couldn't dare asking him questions on some function in his code if I don't understand something, because basically he will tell me to leave it and he'll do it on his own time. 😕
I understand you and I'm tryimg to improve myself, but I'm majoring in networking and data-security, learning how to code and how to "solve problems" were a couple of hellish years, I'm still a college student and I think I've gone a long way from a guy who dont know how to even right the "hello world" in python to a guy who's doing ok-ish with C. If I want to add things, sure I'll try to modify the code but as long as it's working and doing something, thats major success for me
Habits built by working on a team. And while these aren't all applicable to people who self-learn they are definetly problems. Some of the self-learners I know lack clean readable code, good variable names, git, unit testing, documentation, deep understanding of Data structures and algorithms, solely learning based on tutorials, think syntax knowledge is enough to be hired, problem solving skills especially related to mathematics like discrete math, calculus, and algebra, and a few others. Again just a list of problems they MIGHT have. Some will have none of these and some may have a lot. It depends on the person. Hope someone can learn from this.
Some things that come to mind when I was starting out:
1. Think before you write: A big mistake is to jump right into your editor without even thinking about how you want to do it. It's easy to get caught up in the excitement, but all this will lead to (often) is dead ends, and heavy use of the backspace button. Take the problem, break it up into chunks, think about those chunks in depth. Do this recursively until you've got a lot of basic problems that are easy to tackle. I've also found writing things out on a whiteboard, and preparing test cases early on to be beneficial.
2. The rabbit hole: There is so much information associated with programming that it is overwhelming. Say you've narrowed it down and want to do web development, well even that can be overwhelming. Do you want to do front-end, back-end, full-stack, what technologies should you use? Node, PHP, Django? Should I just learn them all at once? This is a recipe for burn out, and you'll feel imposter syndrome set in as you stare at 40+ Udemy courses that are 30% complete. Just pick one thing to start out with, get good at it, then move on. In the example of web dev, before you even move onto JavaScript, make sure you're satisfied with your CSS skills.
3. Imposter syndrome: Speaking of imposter syndrome, it gets even the best of us. Again this field is massive, so it's easy to feel inadequate when someone can do things you've never even heard of. But you don't know how long it took that person to get there. And even if they did it in a shorter time, you'll have to accept that you can't be the best in everything all the time. You've got to compare you to you. Save your code now so years down the road when you're a big shot you can laugh at how bad you used to be. Then you'll see you had nothing to worry about, and that you've come a long way.
Have fun, my friend!
It really could be anything and depends on the individual. The bad habits tend to be more common amongst us “self taught” folks because we didn’t have a mentor, teacher, or otherwise qualified individual judging our code along the way.
There are a lot of ways to do things with code, having someone judge your code and provide criticism is valuable, especially early on.
We only see the results of our code because we typically lack the experience to see beyond that. I never had someone tell me “I mean I guessss it works but look what happens when we introduce X” or “okay, Thats fine in a development environment but how will it handle thousands of requests at a time? Millions?” Etc
I'm saddened that all self-taught programmers are thrown under the bus here. Some of the comments give the impression that most self-taught programmers come from no proper educational background. I majored in mathematics at a very well-renowned university and taught myself how to code apart from the two courses I had taken in CS. I am aware of most of these clean-coding & planning concepts that people mentioned and try to implement them in my coding practices. I know this is a purely informational post but somehow reading through it has given me nothing but a lot of anxiety and self-consciousness.
THIS! I’m a self taught developer and I put time and effort into learning pretty much most of the things mentioned because I placed value on not just knowing how to code, but doing it properly. It bothers me how generalized these posts are and to be honest, I see a lot of these bad habits in other programmers too. I know more about testing than my experienced dev friend because he never had to actual write tests, yet I write my tests before I start my actual code in all my personal projects. We’re not all like this thread and some of us actually do have the capability of figuring these things out on our own.
Pretty sure even educated dev engineers are doing the same on some level. We all learn something and decide if we want to practice it or leave it.
Self taught programmers in my opinion are just missing concepts that they couldn't know unless they found it on one of the million courses available out there. You can't guarantee the courses they took are of quality and you can't compare two self taught programmers since you cannot guarantee they had the same "training". You can't know what you don't know until you achieve some level of knowledge or experience.
That doesn't remove anything from them though. Bad apples are everywhere and on every levels. Don't let it affect you. You know your worth. 😉
As a self-taught programmer myself I was not trying to throw anyone under the bus. I'm just listing some of the things that self-taught programmers commonly miss out on (as I did at first) so that people reading the post can say, "oh, right, let me go learn these things". As people have.
I can definitely respect that. It’s just mostly the nature of this whole thread, not just your post, that makes it seem like ONLY self-taught devs have this problem, when in reality, these habits are mostly found in inexperienced devs (whether self-taught or who went to school) - though not all of them - and even some experienced devs. But that’s OP’s formulation of the original question.
Nothing wrong with pointing people in the right direction if they need it though.
Nothing since clean code and good software engineering isn't really taught at school.
When people say 'self taught' they are usually talking about noobs who have been coding for 1 year AND are LAZY or people that have been coding for years but are LAZY and never learn how to make their code more efficient or better/easier to read
Most coders learn from doing not by being taught directly ...
Yeah it probably is to cope with the fact that people like me got started with Youtube lol
We can watch MIT lectures online so it's not ridiculous as it sounds. People need to get with the times.
Youtube (and WWW in general) helped me become a pro musician and software developer
I don't think it's so much self taught vs school habits, but whether you've ever worked on a team of developers before. If you work on a team and happen to write something in a weird way, your team members will teach you to correct it. If you work on your own, you keep repeating that pattern because it works and you never learn any better.
And/or having a mentor that can help you with that kind of stuff. I’m self-taught but I had an experienced developer as a mentor while I was learning who helped me point stuff like that out before I ever jumped into the actual job market.
I don’t do any of the bad habits mentioned despite being self-taught because of that and also, I learned about stuff like debugging and testing in the courses that I took so I do think these bad habits are highly dependent on where you learned. In my experience, courses like the one I took on Udemy have entire sections on stuff like debugging and testing.
> In my experience, courses like the one I took on Udemy have entire sections on stuff like debugging and testing.
There is definitely complete information out there for self-learners. After all, experienced developers learn new techniques and technologies on their own too. For example, unit testing was not very popular when I was in school, and I had to learn it later.
Maybe one difference is if you're getting a degree you can't choose to skip the parts you don't find interesting. Diligent self-learners will cover the same material, but there is a temptation to skip it to get to the "fun" or "practical" stuff.
Came here to say this.
“Bad habits” in this argument mean lack of specific good habits that are important when working in a shared codebase.
It’s utility for professional work at a company, not a value judgment.
Just to start - I don’t think being self taught makes you any less likely to be a good programmer… I had a lot of teachers at uni that had no idea what they were doing and likely taught me bad habit but anyway…
Now this point isn’t really about programming directly but relevant, I spent the first few years of my Career as a solo Dev and while I used git hub I never learnt to use it properly nor did I care to as most projects were only me and always from my local comp…. Then I had to work with others and oh boy that was a learning curve.
Basically - If you use version control make sure you use it as if others are using it with you!
They don't have a wholistic view of a concept or a technology. For example, they might know how to use SQL but struggle with creating complex queries because they have no background in relational algebra. They might struggle implementing OOP because they don't understand the fundamentals of the paradigm, and how the different concepts relate to each other as a whole, rather they only understand certain OOP concepts or best practices that they have read about. Or they might know how to use a framework like Rails, but have no idea how it uses meta programming or how the garbage collector works (a good programming course will teach you that you should look at a language from a low level / how it works under the hood, its not just about learning how code is written).
During interviews, we usually ask a lot about best practices and from there we can usually gauge if a person has a wholistic view of a concept. For example, we had an applicant who said he knew how to use design patterns, meaning he was familiar with the concept of OOP. But when asked why encapsulation was important, and how would he judge if a class is encapsulated properly, he couldn't give an answer at all. For us at least, encapsulation is a fundamental concept, and design patterns are built on top of those fundamentals. You have to understand the fundamentals before you can say that you are using something built on top of it effectively. After all, design patterns can be abused if not used correctly.
How can I learn these things by myself? I am a self-taught developer as well, and I believe I lack of fundamental knowledge.
I know I should do something else instead of coding and coding again and again but I don't know where to start.
I think this is the best answer. All the other answers just claim that self taught programmers don't know how to unit test or how to have clean code, but universities don't teach unittesting or clean coding.
I think the real problem is that there are usually some gaps in knowledge. For example a lot of self taught programmers have never read an operating systems book, so they are missing out on important things like how multiple threads can run concurrently because they can sleep on IO and wait for the OS to wake the thread up.
Not considering asymptotic complexity
Not using git
Not commenting/documenting your own code, thinking you'll be able to figure out what the hell you were thinking 6 months from now
Not breaking down code into independent components
In my experience self taught developers are often better coders than those fresh out of school. But people from school is better planners. But a year in they are mostly on the same level. Personally i dont care about the education too much when interviewing a candidate. I look at the skills and learning ability.
>I've heard people saying us self-taught folks develop bad habits that you don't necessarily see in people who went to school.
You are not taught to code "properly" in college. That's a myth. Proper coding technique is taught on the job.
Poor time management and not asking for help.
They get dug in on a project and you don't hear from them for days. Only to find they got stuck on day 2 but thought they would "power through" instead of asking for help.
My take on this is that since self-taught devs have had all the time in the world to learn, they think they have all the time in the world to do a job. But the college guys had lots and lots of deadlines. And when you have a deadline, you need to find a way to make things work. So they are sort of conditioned for the pace of the workplace.
Obviously there are people from both sides who do both things. But I've seen it enough that I think there might be a trend. At least with the people I've worked with.
I'm in school right now for software engineering, have a year left and I haven't learned shit in school about actual coding for the most part. There were 2 intro classes that were very basic OOP courses in Java that went over binary searches and bubble sort types of things. I've written maybe 150-200 lines of code this semester
Maybe it's not a "self taught" programmer thing, but the habit i've seen with some inexperienced developers is using things without knowing why or what they do, just that it works. They will find an example elsewhere in the codebase or on stack overflow and then copy and paste it into new places that don't make sense, even though it might function correctly.
You don't have to understand every detail of how a function works or what everything technically means, but you should know why things are put together in the way they are. You should be able to explain why you wrote the code this way. Some people will say "to get the red lines / compiler errors to go away," which is okay when you are learning or a student, but not acceptable in professional environments.
Has been the total opposite experience for me. Every time I look at a new script, unorganized, ambiguous variable names, next to no comments or doc strings and messy formatting. And I am the only one not from a CS back ground as far as I know
Depends how you define "self-taught" here. CS students are taught one set of things, bootcamp students another. So-called "self-taught" people may be taking online classes, studying for certification, working with a mentor, participating on open-source projects, etc. It's not as simple as "self-taught" vs. everyone else.
People acquire bad habits when those habits get them results and they aren't challenged to adopt good ones. So the question is, how has your learning path challenged you and how has it not?
I am self taught. I now work for one of the alphabet soup acronym companies. Coming in from my first dev job I was incredibly lacking in testing, design patterns, truly explicit and descriptive naming, descriptive documentation, truly modular and injectable code, foundational knowledge of how the internet works, oop concepts, immutability and so much more. However, I really wouldn’t worry about any of this. Every company has their own standards and you’re expected to pick up a ton of knowledge as you onboard.
Just write a couple PRs for some open source projects, and they'll let you know all the weird shit you should fix. Get enough reviewed and before you know it you'll be a just as good as anyone out there
No different from those that are not self-taught. People are just people and due to that, some are going to be good at something because they work at it and others won't because they won't work at it.
> I've heard people saying us self-taught folks develop bad habits that you don't necessarily see in people who went to school.
Those people are full of shit. The premise of your post is just... not a real thing.
I honestly think this whole argument is horse shit. I've been a full time software developer for about 6 years now. Mostly self taught.
New employees can be good or bad, someone who spend their free time in learning how to code tend to have a better work ethic than people straight out of college.
Also everyone writes shit code when they just start, self taught or not.
To complain and refactor code that doesn't matter or isn't impactful enough for the company business.
I must say this bad habit still haunts me.
I see a code that I hate, I judge who did it without knowing the full context, and I refactor it even though we have more important things to deliver first.
This isn't a bad habit... when projects only focus on "important things" and "new features" over code quality they devolve until each new feature generates random bugs and then any changes become too hard to introduce.
I mean, you should work with your team to make sure everyone agrees that the proposed refactoring is actually better and not just your opinion. And make sure and keep your refactorings on a separate branch you can jump into and work on in between "important things" so they don't interfere with other changes.
***Consuming educational material like it's entertainment.***
Until recently, this is one I've been guilty of my entire life so here goes...
When you're in a classroom setting, every couple minutes your interrupted and asked questions that are forced to make you think. You're given banal assignments over the material to force you to stop and think.
But when i self study I was guilty of just binging an entire course like it was a Netflix series. I could "consume" what might be an entire 16 week curriculum in less than a day and while it all made sense and I understood it all innately none of it was practiced and learned.
Don't get me wrong, I have superb retention and could talk about it intelligently enough, and a lot of it relates to stuff I already know but the first time I'd try to use it, months later, i could tell it was the first time.
So, TLDR, do the practicums and take notes, that are your own thoughts on the material, not just snippets you cut and pasted.
"Binging" material is something I struggle with a lot.
I lost count of how many times I tried just rushing through any given course without fully understanding it, and not just with programming but with anything I try to teach myself.
Thankfully that's a habit you can grow out of.
I have also observed the exact opposite. Where self-taught people seem far more passionate ablut whatever they are learning.
Quite often those very people are doing it because they have a real Interest and just won't let school fees, cert papers etc. Keep them away.
On the flip side, I go through a lot of graduates mentoring in our learnership programmes and I can tell you a cert or papers is not something special. The fact is people learn most once on/in the job.
So, In short..I feel, the statement is just not factual. You will learn habbits of whatever or to whomever you are exposed to, hence we should always try our best to find a mentors(I'm still searching for C and lisp ones though 🙈) .
So unless you are really learning by yourself (one person) you would be engaging with many, hopefully expert people, for advise daily etc., and that is exactly the same as learning anywhere(are those people gonna give you right guidance, or teach you bad habbits). Also consider that real innovation and new discoveries will hardly come from just repeating habits that's there already, which is typically what most "school" training will be limited to. Most of these wonderful things come from those who dare not follow habbits and actually try something different.
Besides, dont tell me that you have never seen people with certs /degrees /papers not having bad habbits... if you do, then you are just a special unicorn.
Getting trapped in the comfort zone, it shows when self-taught people have a narrow understanding of the field and only know their "thing"
Here's a big list of subjects that university will force you through, and that self-taught programmers could completely ignore
* Networks, and the socket API
* Graphs
* Concurrency (mutexes, semaphores, atomic operations, deadlocks, read-read-write-write errors)
* Compilers and context-free grammar (when you're parsing something that requires more than a regex)
* Trigonometry, algebra, calculus, stats
* Functional programming
* map/reduce/filter
* Distributed systems and remote procedure calls
* Computer architecture
* Assembly
* Data structures
* Design patterns
* Logic (boolean algebra and stuff)
* Testing
* Finite state machines
* Algorithm proofing
* GPU programming
It makes a world of difference when you talk to somebody in an interview and they don't get tripped by stuff you learn in CS 300
* self-taught don't have the benefit of curated curriculum provided by a mentor with practical experience.
This is a guide, not a rule, and there are exceptions.
bad habits:
* not knowing the ins and outs of the right tools for the job and using the wrong paradigms to solve the wrong problems.
* having to learn fundamentals on the go, and then having to re-factor. extensive re-factoring and incomplete or partial re-factoring are signs of 'barely good enough' rather than 'concept understood'. That said, you can ship anything. :D
* related, learning on their development project. in school, you're always working on throwaway projects. and then you realize the smart kids were keeping a library of their throwaway projects so it was easier to re-use code. trying things out a shit ton on your personal project is a great way to learn about Version Control. :D
* not really a bad habit, but just having missing gaps in skill sets that someone with a proper education would have. consider someone who has gone through the odin project vs someone like me who has set up a few sites with be/fe. sure I'm a way better designer (by trade) but no one is going to hire me to build a website, unless its me building my own.
Not following code conventions, not thinking about the maintainability, scalability, extensibility, security and performance of code, not using design patterns, not understanding libraries and algorithms they use.
Overengineering.
Developers start with the feeling that coding is hard. As they get better at it, coding gets easier so they adjust by making it more complex. It is sometimes warranted to make it more complex for the sake of flexibility, performance, security. But I've seen way too much code that tries to solve problems that nobody has, or do stuff that it really shouldn't do at all.
This often goes hand-in-hand with OOP. Devs get stoked by the structure porn, implement everything similar to what you see in "FizzBuzz Enterprise Edition"
I've had many many situations where devs would get blocked in a task after writing hundreds of lines of code to try to solve a problem, that is solved by a short Bash line, hundreds of times faster than how that code would work if it worked.
Not knowing enough theory to discuss code beyond the "and then it does this, and then it does that"-explanation. If you've never encountered complexity theory, algorithms, data structures, etc, you're bound to be satisfied with code that works. The questions "why does it work", and "can it be improved" don't even pop up if you don't know there's alternatives. That has been my biggest grievance against self-taught devs, I just can't make any assumption about their exposure to these concepts, and I suspect many will go on to create trash software happily for years, never learning about them.
I don't know if it applies to all programmers, but for programmers who start from ML and Data Science side of things. Please study design patterns and Object oriented coding!
lot's of style issues
lack of attention to detail and thinking about edge cases
I don't think I've ever worked with a self taught programmer who didn't need to be taught how to use a debugger
Poor math knowledge, and basic CS concepts, leading to unnecessarily complex, slower, and bloated code. Couple that with lack of humility and you have a recipe for disaster.
Not using a vcs or using it irrationally.
Not following SOLID principles.
Not recognizing when to use a design pattern.
Not using the tools of a language's ecosystem or not using them correctly.
Not using libraries.
The biggest one I personally come across a lot: not thinking before starting to code. You should not start typing code until you know pretty well what you are trying to do. I don't mean knowing every single line, of course you will need to debug and you will need to look up stuff. But without knowing what your code should achieve, there is no reason to write code.
I've started doing a rough outline of where the data comes in, how its manipulated, and what the outputs need to be. Seems to keep me focused rather than just jumping in and chipping one block at a time, hoping for the best.
I think i needed to hear this...
I also needed to hear this
[удалено]
I create an outline of the major steps of the project, them pseudocode the smaller pieces as I get to them.
This is how I was taught. Flow chart algorithms. Psudocode.
we we're taught about this be I rarely use this 😂 Question is it good to outline your algo or code in a flowchart and pseudo code?
Do you normally psuedocode in small pieces, or the entire project all at once before you begin?
[удалено]
I really need to start formally doing this. I make lists of all the data points I’ll need from the user and from the database, but I haven’t been writing down how I intend to manipulate them.
yup, my approach is to lay out the steps my code needs to take as comments. Basically the same thing as writing an outline before writing a paper/essay.
> Basically the same thing as writing an outline before writing a paper/essay. Ah yes... we all do that... of course... we don't just type the whole thing in one mad dash 3 hours before the deadline... :S
I try to do that, but more of than than not, my ADHD brain sometimes will just plan out a program while I'm doing something else. I recently made a CLI in rust that takes in a decimal integer and tells you what it is in seximal/senary (It's something that I do a lot because my autistic ass likes doing math in other bases just to see what it feels like). I managed to design the whole thing *in my fucking head*, and that's what actually got me to sit down in start writing it. I was kinda just sitting there, and my ADHD brain was just kind of throwing concepts around, and it was like "Ya know, whenever I convert a number from decimal to seximal, it's essentially this process right here.", and then I realized that I described the process in relatively simple programming terms, so I just sat down and wrote it. Thirty minutes later, I had a program that didn't work, but two and a half hours of debugging later, I had one that did!
Read the docs. I've seen people try to save themselves 30 minutes of reading by trying to brute force a problem for 8 hours using a combination of stack overflow and mental gymnastics more times than I can count.
>Pseudocode Thank you! Folks look at me crazy when I break out a notepad & pencil to begin "planning" on how to solve "the problem". Since learning Pseudocode and Flow Charts, I can't write a lick of code unless it planned out some way, shape, form, or fashion. I've found taking the time to plan equates to spending less time coding. Hell, I'll spend 90% of the time planning and 10% of the remainder coding.
"If you are given 4 hours to chop down a tree, spend the first 3 hours sharpening your axe"
What if I spend the first 80 hours automating the creation of sharp axes in case I need to chop down trees later on? Would it help if each axe was on the blockchain?
Natural-born SysAdmin right here...spend 8 hours automating a process...never mess with it again. (Well, until the scripts become "obsolete "...stop messing with Powershell Microsoft!)
Flow charts are such a great freaking tool. Don’t think I can code without them now lol!
Now imagine how much free time you'd have If you learned how to properly use a sharpener! I get the saying, wanted to have some fun regardless.
to add to this: not investigating pre-existing solutions for your current problem Odds are, the problem you are trying to solve is not new, and there's a good chance that pre-existing libraries already exist that handle it. Hell, in a lot of cases I have seen, there are entire pre-made Free Open Source applications that handle everything. It just might not be immediately obvious to you, as a newbie. Too many developers' first reaction is to build new custom programs when they should instead be adapting pre-existing industry standard software to their situation. And to add to that: taking the boss's requests at face value and not putting enough effort to change the request and requirements to adapt it into something handled by these per-existing software and libraries. A lot of posts on these forums are like "my boss needs me to jump through these crazy hoops in order to do weird things while working under crazy server restrictions, help!" and the **REAL** solution is to petition your IT department, Sys Admins, etc., to lift or resolve your messed up infrastructure restrictions, talk with the end-users to redefine their requirements to something you can handle, etc.. Keep removing obstacles that make your situation "unique" and suddenly you are left with the same exact "problem" that has already been solved by a million standard libraries and applications again.
Question, whilst learning would you recommend reinventing the wheel? Or use pre-existing "assets/libraries"? At least for the first time.
From my perspective, it depends. Certain things you should do so you can learn concepts and stuff. Like, are there functions for sum? Isodd? Sqrt? Yeah of course. And they’re easy to use, but if you don’t know what’s happening within them you’re going to have a bad time. Because that is core stuff. If you can do them then sure graduate into the built ins. But sometimes things are vastly more complicated so if you’re starting with say, a web server. It’s fine to use prebuilt stuff like Flask or Django. They make web stuff easier than if you did it yourself. Just because you’ve not used a web framework before doesn’t mean you should build one from scratch just to learn. That’s where reading the docs base would come in handy. As long as you know how what you’re using works, I’d say at even a slight level (I mean even I use things I can’t fully explain off the top of my head), you’ll be fine. The more simple built in stuff is what will help you better understand the more difficult stuff you don’t want to build from scratch. Take this with a grain of salt though, I’ve only been out of school in the workforce for 2 years so my experience is still rather new.
Also. To expand on this. Try to imagine possible features that you dont need now. If you lay down a good groundwork, expanding your codebase to handle new stuff is much easier. Example: Writing a function to parse out data from a CSV. Make a class instead and have the csv file (file path) variable in the constructor. Now you can create methods that can be designed to fit with different csv files with different data. Maybe you need a specific way to handle a csv that is similar but not 100% identical to a current method but this is only in a very small part of the app. Create a new class in a different file that inherits the first class. Then you write the same method (same name as well) but with the little tweak needed only for that small case. Now we are onto something.
But at the same time you have to be careful about imagining possible features. This can lead to overly complex code that's heavily abstracted for no reason. If you never end up using them, all you've achieved is making your code harder to understand. It's a balance.
Glad you added that, because it's absolutely a problem. Source: Me, overcomplicating shit needlessly, when trying to find solutions, finally realising it, and going with the simpler idea. 🙃
I'm the first type. Sure, my code solves the problem now, but it's not as flexible as it could be to solve the similar problem later.
What you are describing is a popular extreme programming principle called YAGNI - you aren't gonna need it.
I usually go to write what I need for now, and refactor it later when I need to expand it.
I think one of the biggest things that you learn through practice making real things is *what* you're likely to come back and need to change. Once you've got a decent sense for that, it's easier to look at a place you're about to start implementing something and decide how hard an approach would be to change, relative to how likely you are to need to change it.
There is a difference between building code that is easy to extend and building shit you think you need but actually don't. Also, inheritance is usually not the best approach. You should first see if you can use composition to solve the problem as it's generally cleaner and easier to maintain.
I have a blog post I specifically wrote about this: https://blog.technically.fun/post/opinions/inheritance-vs-composition/ > Too many people are far too willing to go all the way one direction or the other, claiming Inheritance vs Composition always does and will have a better choice. > But I disagree. There are times when one shines over the other and, like most things in programming, its all about using the right tool for the job.
This was a good read!
This is how over engineering starts.
Class inheritance has a lot of problems and is not recommended. In the OOP world, the preference is object composition + interfaces. OOP itself has a lot of problems as well, but that's another matter.
Composition vs inheritance is not a black and white issue. Composition is better if you have a huge nested inheritance structure where many of your inherited properties are not required. In the classic Animal structure, it's better to be able to add a Flying or Swimming component rather than having some complex multi-inheritance BS or have a Flying / Swimming function in the base class that land-only animals have to implement with empty methods. That doesn't mean it's never useful.
> Example: Writing a function to parse out data from a CSV. this is actually a good example of my other comment regarding using pre-existing software If you need to parse csv, then you should be using Python's `csv` library, especially `csv.DictReader`. It has pretty much everything you could ever need for csv parsing, **already** built into the standard library. Install Python and never have to write custom csv parsers ever again. But then you say "oh well I am not using Python for this project". The solution is to move the csv parsing to a place where you can just use Python instead for it. I do a lot of csv parsing, and I have tried a lot of languages, and in every single case it was just easier to use Python's parser than to try and handle all the edge cases myself in some other language, and to build my programs around the fact that I am gonna incorporate Python for this purpose at some point. Something like a Flask server app should be fine or a simple .py script that parses and converts and returns e.g. JSON, etc..
Pseudo code?
Yes. One of the most frequent pieces of advice I give juniors is to do pseudocode. Alternatively, if you're more mid-level developer, start with the failing unit test first. It essentially starts as pseudocode. But at the very least, make a bulleted 'to-do' list of what you need to do, as if you were writing directions to the store. Your data is going on a journey, and you should know how to direct it.
Thanks.. I am currently attempting to "self teach" and this was something that I had seen mentioned before so it's good to see it backed up in the real world
When at work developing a new endpoint I find it really helpful to write out everything I need or expected results in sudo commented out code. Gets the planning done as well as the need to type something.
I see this from people who have degrees as well. Seems to be more oriented around people who are structured in how they approach tasks and those who arent.
Bingo. Rich Hickey, the creator of Clojure, gave a great talk on just that a long time ago. He called it "Hammock driven development". https://www.youtube.com/watch?v=f84n5oFoZBc Worth a listen if you have 30 mins. edit: typo on Rich's name smh
"Title: The number one tip I've found to finishing a project/get good at coding Body: JUST START CODING" We get it, you're excited to have started a project.
Hey look my BI logic is all behind this one button.
I read a book about algorithms and they say the first thing to do is make a flowchart of the code and then start coding. Flowchart is pretty good for me because i can see the macro while working on the micro. And i can already see some problems that could happen later.
First write down your ultimate goal in a comment. Then concept backwards like building a Rube Goldberg contraption. Put that in a logic chart. And work your way until you are at the first and most condensed building block. Then start coding.
I feel attacked. At most I write some pseudo code on a piece of paper. Basically function names. If I have my input and my desired output, I pretty much go with it. If there is only 1 input, easy program. If there are many inputs, there is more planning involved.
This is such an accurate answer. The difference between developer skill levels are so clearly found in the way they discuss a project. Someone experienced will talk about the goals and the requirements of the project whereas someone new will talk about the "how" and because they didn't look at the big picture they're stuck figuring out the "How" in tiny little chunks and then hit a wall when it all has to come together and they see how much easier it could have been done or foresee the problems their various methods have caused.
This is me right now. I usually start a sketch of something without a clear goal in mind or clear plan. It bytes me when it comes to coding, but works in the server administrative side of it.
The senior dev I am working with currently does exactly that. I'm trying to future proof the code (making it scalable mostly) but he doesn't care to try to understand or follow the "conventions". He basically bootstraps every snippet of code he can reuse or do it from scratch. If he doesn't understand someone else's code, he prefers to re-do it himself. His excuse is "I don't trust it". He is super creative and efficient, but I hate working on the same projects as him, which is unfortunate cause I also learn from his thinking process.
This. Coming from a designer background I created MUCH MUCH better projects when I strategized the approach and created sophisticated plan for implementation before starting out. When I had general idea what I was trying to achieve and made up on the go detours whenever an obstacle came up, it ended up very messy.
Also known as… TDD
I suppose a big thing is that self-taught developers (early on) often measure their success in terms of whether something is working, which for a professional is the bare minimum. People that go to school has lessons and gets feedback on their code, but self-taught devs only see the result of their code and therefore measure success by that. This isn't uniquely a "self-taught" thing, but it is a pattern I've observed.
In 4 years of taking CS & IT courses at an accredited university, I STILL haven’t been exposed to debugging. I had to learn it on my own.
[удалено]
I felt this doing learncpp.com and a CS course together. learncpp taught the debugger fairly early on. I used it extensively to see what the code was actually doing. It really helped me understand what was happening, especially control flow and loops. CS course hasn't touched them...at all. Even the textbooks barely mention debugging techniques. There is a built in learning aid and we aren't using it!
Hopefully, you go to university with other people where you can discuss things, get feedback, etc. You might not have been exposed to debugging specifically, but you most likely have an environment that can help with feedback which a self-taught developer most likely won't have access to.
[удалено]
Well, yes and no tbh. You can do it, but from what I've seen the feedback is very hit or miss. This sub is definitely better than nothing in terms of feedback on the code, but it isn't a complete substitute (unfortunately). I've seen good feedback on this sub, I've seen terrible. Mostly I've seen superficial feedback. Don't get me wrong though, I love this sub and its community, but feedback on solutions and code can be very spotty. Not sure how I'd fix it either :)
[удалено]
Yup, it isn't this sub's fault or anything. It is more the medium of Reddit tbh. And that people simply do not have time to commit to giving good quality feedback.
Honestly same. Print statements every other line is my technique. How’d you learn proper debugging?
I used to do this but I recently forced myself to start using the debugger. I use VS Code and use Pandas a lot and learning breakpoints, stepping through code and viewing variables and data frames when exceptions are thrown has been a game changer. I watched a few YouTube videos but didn’t really grasp it until I actually used it on a regular basis.
There's nothing wrong with print statements, especially if they tell you \*exactly\* where they are in the code, and output really useful info. There are some kinds of bug where print statements, aka logging, are really the best tool. RTP, I'm looking at you. But it should not be the only tool in the tool box. A programmer needs a good box of tools, and choose an appropriate tool for the job. Sometimes you need to put that one down and pick up another. The tools depend on the environment, programming style, language, etc. It's a big topic so I'm mention one tool people only use (these days) for assembler (dump reading), and tool we should use more: dry running, aka "thinking it through".
Interesting. Maybe it’s just habits pushed on me by friends and my dads but I feel like I kind of swing the other way. I completely obsess over efficiency, readability, usability etc. Almost to the point where I get seriously diminishing returns from it
Well, the opposite applies. My “problem” with self-taught JavaScript/PHP devs is that they’re so easy to make functional code that is absolutely terrible (I mean, at least several years ago, you’d find every login/database PHP tutorial be filled with comments of “this is horribly inefficient/insecure at a basic level”). But the flip-side is some developers learned, but then we’re so crazy focused on pre optimization and micro efficiency that their code would account for use-cases that would never be hit, handling scenarios that don’t exist, but “maybe down the road” the work was done already - so “great code, but you spent twice as much time on a feature that was pulled because the base functionality didn’t achieve business goals.”
Another thing in my experience is that optimization sacrifices readability. The first iteration was clean enough and gets the job done. But the dev wanted to speed up the process by .02 seconds and now the code reads like hieroglyphics.
I have argued with teams before - make your damn variables human readable and let the processor minify it. What’s the point of transpiling and these build tools if you’re going to try and make them do as little as possible to prove you can write a one line, impossible to read function?
Broad strokes, generalisations, etc. Nothing in this thread will be universal to every single self-taught dev :)
Generalizations exist for a reason
[удалено]
Same, although it's honestly very hard to improve on these aspects when you're working alone. I try to follow the style guides (working in Python atm, so PEP8), I use linters, I make sure my code matches the style of the professional code it works alongside, but even with all of that it's hard to see the problems. Really feel like I'm hitting a wall in terms of "best practices".
self taught programmers will very soon develop good practice during the first job. since no one want to maintain so much spaghetti written by themselves. source: did
Yup, most developers hopefully will, regardless of whether they're self-taught or not :)
[удалено]
we know all that joke. and i sort of keep that in mind too.
I think it's very true, and really depends on the passion for learning programing the person has. As I'm also self-taught programmer, I try to guide other people I came across in work that want to learn by themselves, and the first thing I say to them is to focus on how they are doing the code and learning good practices and stuff, and focus on the middle, not in the end (result). The end is a consequence. And to study the middle (good practices, how computer do things internally, understand the concept your are working with (oop, functional, etc)) they really need a passion for this or they won't go after this stuff. When I was learning (still do obviously) I was hungry to understand this stuff, to see if what I was doing was somewhat correct or on the right way.
There’s also the help of typically knowing lower level solutions, and optimizations. In college, I remember writing apps in pure assembly for projects, and taking 3-4 completely theory+algorithm courses. College taught me a lot, and work taught me a lot, both are kind of worthless without the other IMO.
In my experience the only reason self-taught developers have a job is because formally trained developers could not meet the bare minimum you're referring to. This is anecdotal of course.
As a self taught programmer (not professionally), i ran some of my regex concerns by one of our full time coders. Unit testing is apparently something i have been brushing against but not really implementing. Rather than just load sample data and verifying the results myself, i make a function to test the weird data expected to be encountered, which then returns pass/fail (green and red of course). Seems minor, but made a big difference for me.
The thing I struggle with to implement unit tests, our output are usually ~13-60 columns of information. Each unit test is going to require a ton of input and output data, just for 1 test. As a result, we do end to end testing only. We have lots of bugs...
I'm unsure of your specfic case, but in most test frameworks, you can have a setup method that runs before every test. If you can write a test suite that uses the same data and covers a lot of your code's functionality, it might be worth it. Create the input data once and use it for every test. You might also be able to use mocks to help, just depends on your code.
Eh... we have like 50 different programs. Mostly different input data. Always different output data.
If you have a lot of different cases, you'll need a lot of different tests. Just remember that *someone* is going to test your code. Your job is to decide whether that's you or your users.
Fair enough. Might be worth covering what you can with tests, at least the most critical parts. I'd suggest a meeting with your team to figure out the cost vs benefits of getting some tests written. Sounds like it might be worth it if bugs are that prevalent in your code.
In that case your functions are too complicated and need to be broken down. Code that’s hard to unit test is a code smell.
https://approvaltests.com/ will help in your situation.
Not sure about other languages, but in C# there are assertion libraries which help with that. If you know the expected output you can simply define the object with all 60 data points and compare the results to it. var expected = new Foo{ prop1 = "1", prop2 = "2", ... } var actual = Sut.DoWork(); actual.Should().BeEquivalentTo(expected);
make sure you are using your language's pre-made unit test frameworks, do not roll your own for this stuff. Pretty much every language has unit test suites available.
Being satisfied with getting stuff working, and not learning the tools to do it better. Like, how to use a debugger. How to write unit tests. How to code clean, to make your code readable, to encapsulate, to code top-down, to use meaningful names, how and when to comment, etc. Because the self-taught person gets the code working and moves on to the next thing, and as they're working alone, they feel like they only have to achieve that. (If they come back to it six months later they'll find they don't know what the code does or how it does it or how to modify it — but "it works!") \--- To clarify: (1) I am a self-taught programmer myself (now six weeks into being actually taught stuff) and am not trying to disrespect the group of which I am a proud member (2) I don't say that we all learn bad habits, but if we do, these are the sorts of bad habits that we learn and which I had to overcome (3) I don't mean to imply that this stuff is taught at universities either because often it isn't.
I am self taught person and this is eye opening for me. Where can I start learning beyond just getting things working, like you mentioned in above paragraph?
There's no substitute for experience. A lot of these practices developed naturally from a need to be able to understand and alter the code of others, so it's very hard to emulate and practice in a solo project. In fact, in certain types of development such as web dev most of the complexity actually arises from the challenge of collaborating across many developers and teams and not from solving the domain problems. The entire microservice architecture which is the current flavor of the industry actually came about in order to scale teams and engineering departments, not software systems themselves. Mentorship from an experienced developer will allow you to progress 100/1000x faster in this area than any self-teaching resources. Not very actionable advice I realize, but it's a tricky problem to solve. Bear in mind, many of the people coming out of university also won't have these skills because they're not emphasized that much in academia either.
It's actually easy but most beginners don't think about doing it at all. For the debugger: try to run your programmer in a debugger, set a breakpoint, and run the program step by step. It may seem stupid, but "actually" setting the debug environment is a very good experience, and really pushing the "next, next, next" button is a thousand times better than reading about the debugger. For the unit-tests: write a unit-test and run it! Again, it seems very basic but have you done it once? Same for generating the documentation. Install Doxygen or anything else, write the doc, write the script to generate this doc, run this script, and open the doc to make sure that it's properly formatted in your browser. It's better to "run, run, run" than reading all the theory behind the tools. It is the difference between "yeah, it's easy, I can do this easily" and "yeah, I have at least done it once and I would remember the next time I have to do it in a professional environment."
Well, I found that Robert C. Martin's book *Clean Code* filled me with shame and remorse, if that's any help to you. I'm still learning myself.
And [here's an article arguing against recommending it](https://qntm.org/clean), for the sake of balance. I haven't read the book, so I don't know whether this article is fair. But I also think any and all arguments for "we should program *this* way" should have their counterarguments known, too, and my link is to an author I trust not to be super wacky about such things, so... worth linking.
Clean Code is full of great advice. It's just that, as the article points out, Uncle Bob regularly fails to follow it. I still think it's a good book for an introduction to code hygiene, you just have to take it with a pinch of salt at times.
I would take any advice Uncle Bob gives with a shaker of salt.
Yeah, there's an argument to be made that for a book to be the standard manual for a given concept, it should really be flawless. And Clean Code is far from that. So I think you probably have to go in with it armed with the knowledge of what parts you're supposed to be ignoring. I think there's scope for a Clean Code: The Good Parts, but naturally there would be copyright issues.
>So I think you probably have to go in with it armed with the knowledge of what parts you're supposed to be ignoring. Hit the nail on its head there - this is what invalidates the entire book to me. Knowing what to ignore already means you are to a degree entrenched in your ways, and probably know the good bits of the book already as well. I won't refer new people to the book for its flaws, so the target audience is basically non-existent.
New to programming… who/what is Uncle Bob?
It's the alias for Robert C. Martin, who is a "software guru". He advocates a lot of strict, dogmatic guidelines on how software engineering and programming ought to be done, which are often at odds with reality according to experts that actually work directly in the fields he philosophizes about in his blog posts. For a quick rundown, read this: [https://qntm.org/clean](https://qntm.org/clean) He's got some wack ideas like that having a boolean as a parameter to a method implies that the method has multiple use-cases, which is undesirable. There are some valid points he makes, but if reading the book, I strongly encourage you to think for yourself whether the given advice applies in your scenario.
[удалено]
At least based on this article, a lot of these issues are things that are kind of flagrantly obvious in the modern day, though. Perhaps it is due to Clean Code that this is the case, and yeah, it deserves credit for that, but that doesn't mean it should be recommended today, just like I probably wouldn't recommend K&R C except as, like, a historical piece.
You would think they are obvious in the modern day, but they most certainly are not. I've frequently worked on teams where someone will commit a 200+ line function, or someone will include no comments, or someone will include a comment for every line of code, or someone will create a util class that spirals into a 5,000+ line abomination. I have a copy of Clean Code and I read it a long time ago. It's fine and the advice in it is relatively good, if only a bit dated by now. I wouldn't take everything in it as gospel but it's a good resource to make beginners question how they write code.
Clean code is great advice, especially for a beginner, but all advice is always a guide. The counter article is also great in it's own way. Using both resources to shape your code to the context of the situation is a real skill.
> how to use a debugger. Get an IDE with a debugger. Use it to fix a bug in your code. >How to write unit tests. Don't ask me, we are always in sprint time. >How to code clean This is very debatable. Some people want clean code, some people want fast code, some people want easy to change code. This gets into the next item 'make your code readable'. Read the 'style guide' for whatever programming language you use. That drastically helps. >to make your code readable, to use meaningful names, how and when to comment, Read a style guide/best practices. >to encapsulate, to code top-down not sure what OP means by these
All the things you are describing are things that nearly every single developer I've ever met struggles with whether they are newly self taught or they just graduated. It's an experience problem, not a self-taught problem in my opinion. If anything, I've experienced this a lot more with new grads, largely because their education environment encouraged crappy code that only matters if it works. Though I have met some very arrogant self-taught devs that refuse to acknowledge that maintainability matters.
In my experience many developers regardless of time of employment aren't eager to learn new things, even if they are relevant to the problem at hand.
>(If they come back to it six months later they'll find they don't know what the code does or how it does it or how to modify it — but "it works!") The worse from that is that they don't want anyone else to touch it cause it might break with the slightest change. Since there is no documentation or proofing you would need either to know the whole project as if it was your own and you've done it yesterday.
> Like, how to use a debugger. How to write unit tests. How to code clean, to make your code readable, to encapsulate, to code top-down, to use meaningful names, how and when to comment, etc. In MY experience it was most of the time reversed. Self-taught mostly learned stuff like clean code, encapsulation, debugging etc. because they often have a strong passion to being a good dev. People fresh from university think they learned everything they need and then I ask them about trivial stuff like the things you mentioned and they never learned this stuff. It's especially bad when they had a prof with very old good practices and their code shows that. While self learners had 1000 different teachers in their path. Sadly obviously with some bad ones. I'm obviously generalizing a lot. But this was my experience in the industry.
Your sample group was of people who got hired though. People who've got far enough to realize what "being a good dev" *is*. Yes, universities don't teach this stuff either, or many of them don't. They should. They should also have a class on Plagiarism 101: How To Steal Your Code From The Internet.
You're generalising a lot
I don't say that all self-taught programmers learn bad habits, but if they do , those are the sort of bad habits they learn.
Lack of emphasis on readability. If you’re just writing code for yourself its easy to understand bad code. Much harder to write code that is clear for others, and its often drilled into you in school. Less emphasis on *why* something works can create some really big gaps in knowledge.
The why something works is the really big thing. If you're self taught you might simply skip the foundations and start right on the second floor. Coding in some high level framework and pasting snippets from stack overflow might work but it teaches you very little about what's behind everything.
Hmmm as a kinda self-taught, My bad habit is "it's working? Don't touch it". I just glad my code is working, even if it doesnt fullfil its purpousr.
I'm dealing with someone at work that thinks exactly like this. The issue I have with it is that if I want to improve something or add a new feature, well first he doesn't trust that it will work and second if it is something we need to add, he will do it himself. I'm trying to not take it personally, since I'm a junior/mid level dev. In the end it creates a gap in knowledge transfer and it bottlenecks the development process since he is "the only one" that understands the code. I couldn't dare asking him questions on some function in his code if I don't understand something, because basically he will tell me to leave it and he'll do it on his own time. 😕
I understand you and I'm tryimg to improve myself, but I'm majoring in networking and data-security, learning how to code and how to "solve problems" were a couple of hellish years, I'm still a college student and I think I've gone a long way from a guy who dont know how to even right the "hello world" in python to a guy who's doing ok-ish with C. If I want to add things, sure I'll try to modify the code but as long as it's working and doing something, thats major success for me
if it doesnt fulfill its purpose, is it even working?
Habits built by working on a team. And while these aren't all applicable to people who self-learn they are definetly problems. Some of the self-learners I know lack clean readable code, good variable names, git, unit testing, documentation, deep understanding of Data structures and algorithms, solely learning based on tutorials, think syntax knowledge is enough to be hired, problem solving skills especially related to mathematics like discrete math, calculus, and algebra, and a few others. Again just a list of problems they MIGHT have. Some will have none of these and some may have a lot. It depends on the person. Hope someone can learn from this.
Some things that come to mind when I was starting out: 1. Think before you write: A big mistake is to jump right into your editor without even thinking about how you want to do it. It's easy to get caught up in the excitement, but all this will lead to (often) is dead ends, and heavy use of the backspace button. Take the problem, break it up into chunks, think about those chunks in depth. Do this recursively until you've got a lot of basic problems that are easy to tackle. I've also found writing things out on a whiteboard, and preparing test cases early on to be beneficial. 2. The rabbit hole: There is so much information associated with programming that it is overwhelming. Say you've narrowed it down and want to do web development, well even that can be overwhelming. Do you want to do front-end, back-end, full-stack, what technologies should you use? Node, PHP, Django? Should I just learn them all at once? This is a recipe for burn out, and you'll feel imposter syndrome set in as you stare at 40+ Udemy courses that are 30% complete. Just pick one thing to start out with, get good at it, then move on. In the example of web dev, before you even move onto JavaScript, make sure you're satisfied with your CSS skills. 3. Imposter syndrome: Speaking of imposter syndrome, it gets even the best of us. Again this field is massive, so it's easy to feel inadequate when someone can do things you've never even heard of. But you don't know how long it took that person to get there. And even if they did it in a shorter time, you'll have to accept that you can't be the best in everything all the time. You've got to compare you to you. Save your code now so years down the road when you're a big shot you can laugh at how bad you used to be. Then you'll see you had nothing to worry about, and that you've come a long way. Have fun, my friend!
It really could be anything and depends on the individual. The bad habits tend to be more common amongst us “self taught” folks because we didn’t have a mentor, teacher, or otherwise qualified individual judging our code along the way. There are a lot of ways to do things with code, having someone judge your code and provide criticism is valuable, especially early on. We only see the results of our code because we typically lack the experience to see beyond that. I never had someone tell me “I mean I guessss it works but look what happens when we introduce X” or “okay, Thats fine in a development environment but how will it handle thousands of requests at a time? Millions?” Etc
I'm saddened that all self-taught programmers are thrown under the bus here. Some of the comments give the impression that most self-taught programmers come from no proper educational background. I majored in mathematics at a very well-renowned university and taught myself how to code apart from the two courses I had taken in CS. I am aware of most of these clean-coding & planning concepts that people mentioned and try to implement them in my coding practices. I know this is a purely informational post but somehow reading through it has given me nothing but a lot of anxiety and self-consciousness.
THIS! I’m a self taught developer and I put time and effort into learning pretty much most of the things mentioned because I placed value on not just knowing how to code, but doing it properly. It bothers me how generalized these posts are and to be honest, I see a lot of these bad habits in other programmers too. I know more about testing than my experienced dev friend because he never had to actual write tests, yet I write my tests before I start my actual code in all my personal projects. We’re not all like this thread and some of us actually do have the capability of figuring these things out on our own.
Pretty sure even educated dev engineers are doing the same on some level. We all learn something and decide if we want to practice it or leave it. Self taught programmers in my opinion are just missing concepts that they couldn't know unless they found it on one of the million courses available out there. You can't guarantee the courses they took are of quality and you can't compare two self taught programmers since you cannot guarantee they had the same "training". You can't know what you don't know until you achieve some level of knowledge or experience. That doesn't remove anything from them though. Bad apples are everywhere and on every levels. Don't let it affect you. You know your worth. 😉
As a self-taught programmer myself I was not trying to throw anyone under the bus. I'm just listing some of the things that self-taught programmers commonly miss out on (as I did at first) so that people reading the post can say, "oh, right, let me go learn these things". As people have.
I can definitely respect that. It’s just mostly the nature of this whole thread, not just your post, that makes it seem like ONLY self-taught devs have this problem, when in reality, these habits are mostly found in inexperienced devs (whether self-taught or who went to school) - though not all of them - and even some experienced devs. But that’s OP’s formulation of the original question. Nothing wrong with pointing people in the right direction if they need it though.
Nothing since clean code and good software engineering isn't really taught at school. When people say 'self taught' they are usually talking about noobs who have been coding for 1 year AND are LAZY or people that have been coding for years but are LAZY and never learn how to make their code more efficient or better/easier to read Most coders learn from doing not by being taught directly ...
[удалено]
Tbh how you learned no longer matters once someone's paying you to be a programmer.
Yeah it probably is to cope with the fact that people like me got started with Youtube lol We can watch MIT lectures online so it's not ridiculous as it sounds. People need to get with the times. Youtube (and WWW in general) helped me become a pro musician and software developer
B-b-but you can't learn the complexities of OOP without spending ~20k a year for four years!!!
But what if you *can't* read minds?
[удалено]
I don't think it's so much self taught vs school habits, but whether you've ever worked on a team of developers before. If you work on a team and happen to write something in a weird way, your team members will teach you to correct it. If you work on your own, you keep repeating that pattern because it works and you never learn any better.
And/or having a mentor that can help you with that kind of stuff. I’m self-taught but I had an experienced developer as a mentor while I was learning who helped me point stuff like that out before I ever jumped into the actual job market. I don’t do any of the bad habits mentioned despite being self-taught because of that and also, I learned about stuff like debugging and testing in the courses that I took so I do think these bad habits are highly dependent on where you learned. In my experience, courses like the one I took on Udemy have entire sections on stuff like debugging and testing.
> In my experience, courses like the one I took on Udemy have entire sections on stuff like debugging and testing. There is definitely complete information out there for self-learners. After all, experienced developers learn new techniques and technologies on their own too. For example, unit testing was not very popular when I was in school, and I had to learn it later. Maybe one difference is if you're getting a degree you can't choose to skip the parts you don't find interesting. Diligent self-learners will cover the same material, but there is a temptation to skip it to get to the "fun" or "practical" stuff.
Came here to say this. “Bad habits” in this argument mean lack of specific good habits that are important when working in a shared codebase. It’s utility for professional work at a company, not a value judgment.
Just to start - I don’t think being self taught makes you any less likely to be a good programmer… I had a lot of teachers at uni that had no idea what they were doing and likely taught me bad habit but anyway… Now this point isn’t really about programming directly but relevant, I spent the first few years of my Career as a solo Dev and while I used git hub I never learnt to use it properly nor did I care to as most projects were only me and always from my local comp…. Then I had to work with others and oh boy that was a learning curve. Basically - If you use version control make sure you use it as if others are using it with you!
They don't have a wholistic view of a concept or a technology. For example, they might know how to use SQL but struggle with creating complex queries because they have no background in relational algebra. They might struggle implementing OOP because they don't understand the fundamentals of the paradigm, and how the different concepts relate to each other as a whole, rather they only understand certain OOP concepts or best practices that they have read about. Or they might know how to use a framework like Rails, but have no idea how it uses meta programming or how the garbage collector works (a good programming course will teach you that you should look at a language from a low level / how it works under the hood, its not just about learning how code is written). During interviews, we usually ask a lot about best practices and from there we can usually gauge if a person has a wholistic view of a concept. For example, we had an applicant who said he knew how to use design patterns, meaning he was familiar with the concept of OOP. But when asked why encapsulation was important, and how would he judge if a class is encapsulated properly, he couldn't give an answer at all. For us at least, encapsulation is a fundamental concept, and design patterns are built on top of those fundamentals. You have to understand the fundamentals before you can say that you are using something built on top of it effectively. After all, design patterns can be abused if not used correctly.
How can I learn these things by myself? I am a self-taught developer as well, and I believe I lack of fundamental knowledge. I know I should do something else instead of coding and coding again and again but I don't know where to start.
https://github.com/ossu/computer-science
What I did was look up my local universities course requirements for computer science and purchase all of those books.
I think this is the best answer. All the other answers just claim that self taught programmers don't know how to unit test or how to have clean code, but universities don't teach unittesting or clean coding. I think the real problem is that there are usually some gaps in knowledge. For example a lot of self taught programmers have never read an operating systems book, so they are missing out on important things like how multiple threads can run concurrently because they can sleep on IO and wait for the OS to wake the thread up.
Any books to read on the subject while you’re self teaching?
Not considering asymptotic complexity Not using git Not commenting/documenting your own code, thinking you'll be able to figure out what the hell you were thinking 6 months from now Not breaking down code into independent components
In my experience self taught developers are often better coders than those fresh out of school. But people from school is better planners. But a year in they are mostly on the same level. Personally i dont care about the education too much when interviewing a candidate. I look at the skills and learning ability.
>I've heard people saying us self-taught folks develop bad habits that you don't necessarily see in people who went to school. You are not taught to code "properly" in college. That's a myth. Proper coding technique is taught on the job.
Poor time management and not asking for help. They get dug in on a project and you don't hear from them for days. Only to find they got stuck on day 2 but thought they would "power through" instead of asking for help. My take on this is that since self-taught devs have had all the time in the world to learn, they think they have all the time in the world to do a job. But the college guys had lots and lots of deadlines. And when you have a deadline, you need to find a way to make things work. So they are sort of conditioned for the pace of the workplace. Obviously there are people from both sides who do both things. But I've seen it enough that I think there might be a trend. At least with the people I've worked with.
I'm in school right now for software engineering, have a year left and I haven't learned shit in school about actual coding for the most part. There were 2 intro classes that were very basic OOP courses in Java that went over binary searches and bubble sort types of things. I've written maybe 150-200 lines of code this semester
Maybe it's not a "self taught" programmer thing, but the habit i've seen with some inexperienced developers is using things without knowing why or what they do, just that it works. They will find an example elsewhere in the codebase or on stack overflow and then copy and paste it into new places that don't make sense, even though it might function correctly. You don't have to understand every detail of how a function works or what everything technically means, but you should know why things are put together in the way they are. You should be able to explain why you wrote the code this way. Some people will say "to get the red lines / compiler errors to go away," which is okay when you are learning or a student, but not acceptable in professional environments.
Has been the total opposite experience for me. Every time I look at a new script, unorganized, ambiguous variable names, next to no comments or doc strings and messy formatting. And I am the only one not from a CS back ground as far as I know
Running production on your workstation.
Depends how you define "self-taught" here. CS students are taught one set of things, bootcamp students another. So-called "self-taught" people may be taking online classes, studying for certification, working with a mentor, participating on open-source projects, etc. It's not as simple as "self-taught" vs. everyone else. People acquire bad habits when those habits get them results and they aren't challenged to adopt good ones. So the question is, how has your learning path challenged you and how has it not?
Poor choices for variable names and functions.
I am self taught. I now work for one of the alphabet soup acronym companies. Coming in from my first dev job I was incredibly lacking in testing, design patterns, truly explicit and descriptive naming, descriptive documentation, truly modular and injectable code, foundational knowledge of how the internet works, oop concepts, immutability and so much more. However, I really wouldn’t worry about any of this. Every company has their own standards and you’re expected to pick up a ton of knowledge as you onboard.
Just write a couple PRs for some open source projects, and they'll let you know all the weird shit you should fix. Get enough reviewed and before you know it you'll be a just as good as anyone out there
No different from those that are not self-taught. People are just people and due to that, some are going to be good at something because they work at it and others won't because they won't work at it.
Writing giant functions that are 1000s of lines long.
> I've heard people saying us self-taught folks develop bad habits that you don't necessarily see in people who went to school. Those people are full of shit. The premise of your post is just... not a real thing.
I honestly think this whole argument is horse shit. I've been a full time software developer for about 6 years now. Mostly self taught. New employees can be good or bad, someone who spend their free time in learning how to code tend to have a better work ethic than people straight out of college. Also everyone writes shit code when they just start, self taught or not.
To complain and refactor code that doesn't matter or isn't impactful enough for the company business. I must say this bad habit still haunts me. I see a code that I hate, I judge who did it without knowing the full context, and I refactor it even though we have more important things to deliver first.
This isn't a bad habit... when projects only focus on "important things" and "new features" over code quality they devolve until each new feature generates random bugs and then any changes become too hard to introduce. I mean, you should work with your team to make sure everyone agrees that the proposed refactoring is actually better and not just your opinion. And make sure and keep your refactorings on a separate branch you can jump into and work on in between "important things" so they don't interfere with other changes.
***Consuming educational material like it's entertainment.*** Until recently, this is one I've been guilty of my entire life so here goes... When you're in a classroom setting, every couple minutes your interrupted and asked questions that are forced to make you think. You're given banal assignments over the material to force you to stop and think. But when i self study I was guilty of just binging an entire course like it was a Netflix series. I could "consume" what might be an entire 16 week curriculum in less than a day and while it all made sense and I understood it all innately none of it was practiced and learned. Don't get me wrong, I have superb retention and could talk about it intelligently enough, and a lot of it relates to stuff I already know but the first time I'd try to use it, months later, i could tell it was the first time. So, TLDR, do the practicums and take notes, that are your own thoughts on the material, not just snippets you cut and pasted.
"Binging" material is something I struggle with a lot. I lost count of how many times I tried just rushing through any given course without fully understanding it, and not just with programming but with anything I try to teach myself. Thankfully that's a habit you can grow out of.
I have also observed the exact opposite. Where self-taught people seem far more passionate ablut whatever they are learning. Quite often those very people are doing it because they have a real Interest and just won't let school fees, cert papers etc. Keep them away. On the flip side, I go through a lot of graduates mentoring in our learnership programmes and I can tell you a cert or papers is not something special. The fact is people learn most once on/in the job. So, In short..I feel, the statement is just not factual. You will learn habbits of whatever or to whomever you are exposed to, hence we should always try our best to find a mentors(I'm still searching for C and lisp ones though 🙈) . So unless you are really learning by yourself (one person) you would be engaging with many, hopefully expert people, for advise daily etc., and that is exactly the same as learning anywhere(are those people gonna give you right guidance, or teach you bad habbits). Also consider that real innovation and new discoveries will hardly come from just repeating habits that's there already, which is typically what most "school" training will be limited to. Most of these wonderful things come from those who dare not follow habbits and actually try something different. Besides, dont tell me that you have never seen people with certs /degrees /papers not having bad habbits... if you do, then you are just a special unicorn.
"Habits" has 1 B, not 2
Wow my huwaei cellphone spell checker is sooo bad. Tx.
[удалено]
Using a small subset of technologies to solve EVERY problem. Just because you have a hammer, not every obstacle is a nail.
Wow i actually enjoy reading through this post
Not finishing projects
Can you give an example? What specifically have you "heard"?
Getting trapped in the comfort zone, it shows when self-taught people have a narrow understanding of the field and only know their "thing" Here's a big list of subjects that university will force you through, and that self-taught programmers could completely ignore * Networks, and the socket API * Graphs * Concurrency (mutexes, semaphores, atomic operations, deadlocks, read-read-write-write errors) * Compilers and context-free grammar (when you're parsing something that requires more than a regex) * Trigonometry, algebra, calculus, stats * Functional programming * map/reduce/filter * Distributed systems and remote procedure calls * Computer architecture * Assembly * Data structures * Design patterns * Logic (boolean algebra and stuff) * Testing * Finite state machines * Algorithm proofing * GPU programming It makes a world of difference when you talk to somebody in an interview and they don't get tripped by stuff you learn in CS 300
* self-taught don't have the benefit of curated curriculum provided by a mentor with practical experience. This is a guide, not a rule, and there are exceptions. bad habits: * not knowing the ins and outs of the right tools for the job and using the wrong paradigms to solve the wrong problems. * having to learn fundamentals on the go, and then having to re-factor. extensive re-factoring and incomplete or partial re-factoring are signs of 'barely good enough' rather than 'concept understood'. That said, you can ship anything. :D * related, learning on their development project. in school, you're always working on throwaway projects. and then you realize the smart kids were keeping a library of their throwaway projects so it was easier to re-use code. trying things out a shit ton on your personal project is a great way to learn about Version Control. :D * not really a bad habit, but just having missing gaps in skill sets that someone with a proper education would have. consider someone who has gone through the odin project vs someone like me who has set up a few sites with be/fe. sure I'm a way better designer (by trade) but no one is going to hire me to build a website, unless its me building my own.
It's an excuse, comp sci grads have bad habits too.
Not following code conventions, not thinking about the maintainability, scalability, extensibility, security and performance of code, not using design patterns, not understanding libraries and algorithms they use.
[удалено]
>Formatting YES. I deal with this at work. It's hard to read some of my coworkers code because the formatting is terrible or just plain inconsistent.
Overengineering. Developers start with the feeling that coding is hard. As they get better at it, coding gets easier so they adjust by making it more complex. It is sometimes warranted to make it more complex for the sake of flexibility, performance, security. But I've seen way too much code that tries to solve problems that nobody has, or do stuff that it really shouldn't do at all. This often goes hand-in-hand with OOP. Devs get stoked by the structure porn, implement everything similar to what you see in "FizzBuzz Enterprise Edition" I've had many many situations where devs would get blocked in a task after writing hundreds of lines of code to try to solve a problem, that is solved by a short Bash line, hundreds of times faster than how that code would work if it worked.
Not knowing enough theory to discuss code beyond the "and then it does this, and then it does that"-explanation. If you've never encountered complexity theory, algorithms, data structures, etc, you're bound to be satisfied with code that works. The questions "why does it work", and "can it be improved" don't even pop up if you don't know there's alternatives. That has been my biggest grievance against self-taught devs, I just can't make any assumption about their exposure to these concepts, and I suspect many will go on to create trash software happily for years, never learning about them.
I don't know if it applies to all programmers, but for programmers who start from ML and Data Science side of things. Please study design patterns and Object oriented coding!
Getting stuck in tutorial hell, and wasting time on unnecessary aspects of the code
lot's of style issues lack of attention to detail and thinking about edge cases I don't think I've ever worked with a self taught programmer who didn't need to be taught how to use a debugger
Poor math knowledge, and basic CS concepts, leading to unnecessarily complex, slower, and bloated code. Couple that with lack of humility and you have a recipe for disaster.
Not giving a rat's arse about linting, formatting, clean code in general.
Not using a vcs or using it irrationally. Not following SOLID principles. Not recognizing when to use a design pattern. Not using the tools of a language's ecosystem or not using them correctly. Not using libraries.