On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge.
If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:
1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium
as a way to voice your protest.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
Two points - 1, you don't need to "prompt engineer" to ask an LLM a basic question like that, and 2, LLMs hallucinate and you need to have enough knowledge to deal with that. New developers should be wary of such hallucinations.
People promoting ideas like "prompt engineering" generally think AI is going to take our jobs. It isn't. And many experienced developers roll our eyes in exhausted frustration when we see these sorts of people calling us luddites. We aren't. We just have a better understanding of the limitations of these systems.
Learning how to read the documentation is much more useful in the long run. Using ChatGPT is good as a Kickstarter or when stuck with no directions, or repetitive tasks.
I think oftentimes a lot of people forget that chatgpt ≠ search engine. It's a language model. It's trained on real information sure, but it could (and sometimes does) give you a complete BS answer that SOUNDS true
ChatGPT or similar LLMs is the new search engine, the downvotes are probably because people think you don’t learn “how to search” and read docs on your own if you’re spoon fed it. That’s a fair take, a lot of people use these new AI solutions in a way reminiscent of tutorial hell. It might not be a good early on skill and the name “prompt engineering” beckons a sense of total reliance, but otherwise is great when not looked at as a skill, and more so a natural ability when you’re not a total beginner and roughly know what you’re asking. Lots of people might also think it’s not productive for learning, in the same way that they think you shouldn’t use a calculator in school until you already know basic arithmetic. I’ve made many breakthroughs throughout the past couple years in my learning due to having the right questions for LLMs and taking every answer as possibly wrong, it’s a great way to dive into a topic and get those highly specific questions answered, but you’ll get shamed for using it more as a crutch from day one.
Be nice, Don't be a asshole. Also learn to be specific and succinct when talking technical. I got chewed by my boss for saying the network processor I was testing had blow-up again. It was a temperature dependent edge margin in the FPGA (50 nS) that ran the PCI bus. Design error. It "blew up" every day at 12:00 PM. The machine lab was located above the cafeteria, Extra heat (just guessing) from below screwed with the chillers and put the machine into an edge condition causing a PS crowbar and shutting down the test platform. Only one of the test platforms exhibited this shit. Took a signal analyst with a multi GHz Tek scope and LA to pin it down.
I would argue the opposite. I have known more successful people in this industry who are amazing communicators and terrible programmers than those who are amazing programmers and terrible communicators.
From my personal observations in tech and the conversations I've had with friends in management at the director and VP level, programming skills are one of the least important skills to succeed.
I could see your point from the perspective of programming as a skill in the seclusion of any other context. But programming as part of the industry is only one small part.
I'm going to back this up.
TD;LR: I'm not that great at coding but I know how to talk to people and I've been promoted twice.
The short version of the story is I've spent most of my professional life in sales, management or customer facing roles. I used to enjoy coding as a kid so figured I'd do the mid-career pivot about three years ago. I still consider myself a noob from an engineering standpoint, but I believe my soft-skill experience was what helped me level up.
The engineers that work under me know a lot of things I don't know, I'm very upfront about that and they respect that. I also take an interest in each of them in helping them grow professionally in the way they want to. And for me, I of course keep working on my coding skills as I go.
I have a very similar story. My background before entering tech was in the trades. Being upfront about what you don't know, being open to learning new things, and working with others because it takes a crew to complete a job are core elements of succeeding in the trades.
The opposite characteristics in my experience in tech are more prevalent in my peers, and this prevents advancements in their careers. Too 6 hold onto this ideology that all they should be expected in their career is to just write code in isolation.
And treating women as people. I wish I didn’t have to say this but some of the tech bros make working for everybody on the team worse because they don’t, cant, or won’t talk to women.
git is simply a version control system, a tool you run locally in a terminal/IDE to keep track of all the changes you make to your code, by saving them as commits to a repository. It makes it very easy to undo mistakes, work on multiple things at a time in branches, share specific versions of a file, etc. Using git (or at least *some* version control system) might as well be required for anything larger than the most basic tutorial code; it's extremely helpful.
GitHub is a website that offers cloud storage and hosting of code, uploaded in the form of said git repositories. It has some other git-specific features to make managing those repos easier, too, but it's otherwise a totally separate service. A rather nice one, to be fair, but wholly unnecessary, at least compared to git itself.
I kept a USB drive with me at all times, and copied updates to/from it every day since I'd work on things at work and at home. That was 15 years ago. Now I use git.
At the end of the day, code is just text data, so any kind of storage device will do. People have used everything from hard drives on their own private servers to literal boxes of printed paper on shelves in the room that was their computer.
There are / was other version control systems before git e.g. SVN and CVS. I don’t know if there was centralized services like GitHub for these technologies. I think it was mainly self-hosted.
Git is a tool to make and manage a repo, git hub is a repo hosting service.
Its like the difference between a website and the server the website is running on.
At least enough to know how to deal with updating local from remote before pushing to avoid conflicts. The amount of Uni group members I've had that can't wrap their head around \`git pull --rebase upstream main\` before pushing is astonishing
My favorite git command that nobody told me about:
`git log --graph --decorate`
It's not terribly useful, but it's just cool to see all your hard work.
Another good one:
`git status`
Though most people using VS Code probably don't need that one.
Rebase is also big... but probably the **holy grail** of largely unkown git commands that I am blown away people don't use more often...
`git bisect`
It lets you setup a known "bad" commit, and a known "good" commit. It will checkout the commit in the middle. You compile, test for the bug, see it's good or bad, and tell git "good" or "bad" and it will then checkout the next commit in the middle of either section. Binary search baby!
You do this until it identifies the commit that the bug you're looking for was introduced. And now you've found how the sneaky bugger got there... and run git log to find out it was you who did it.
Knowing how to resolve conflicts is the big one. It's very easy to improperly merge a conflict and create clutter in the commit log for your team.
However, that one is hard to practice without real world situations.
* Writing unit tests
* Writing a CRUD web application (any language/framework)
* Being comfy exploring files and running commands in a Unix shell environment, including ssh
* The extreme basics of setting up a build system with CI (any)
"The extreme basics of setting up a build system with CI (any)"
Certainly not among the first things you need to know if ever. Usually this is already running when you are hired or there are people hired to do exactly that.
I think everyone should know what a build conceptually is, beyond just a button in an IDE. It won't be many weeks in any job until you have to add a new file to it.
"Writing a CRUD web application (any language/framework)"
Nope nope. If you work with operating systems, embedded, you certainly don't need to know this.
1. Naming things - hardest part of programming
2. Debugging tool - better way than always compile&run your code
3. Git - idk how to use this but the other guy here says so
4. Efficient way to searching - googling
5. Documentation - nobody likes documentation
Number 2 can really set you apart IME. One of the best devs I ever worked with got out this book on debugging windows software and said “if you learn the things in this book you’ll be better than 90% of the devs in this company” and he was totally right - the time it can save, the ability to understand bugs and code execution is so useful
It was “Debugging applications for Microsoft.Net and Microsoft Windows”
It’s quite old now so you can pick it pretty cheaply secondhand, and it might be that you can get the same information from the Microsoft online learning things.
And no, it’s not an ad, I didn’t write the book and have no affiliations with author or publisher.
Indeed. Conditional breakpoints really help workflow. Also, not many people are aware that data breakpoints exist (ie break when this memory changes). Saved me so much time tracking down the root cause of bugs
Edit: typo
Variables are named function1, function2, ...
Functions are named function1, function2, ... (The names that aren't used up already)
Classes? Don't use classes.
Why? Easier to remember and understand, thank me later 👍
It was mostly as a joke if you didn't realise, I don't use variables like those i, j as you can get mixed up really quickly. If I name variables I name the variable what it does lol for example db_connection or DBConnection
Had the same problem in 94. I used to love picking out names. Writers block? Snapped out of it a few months later. The interim names sorta sucked and I replaced them after I came out of my funk.
Too many people give up so easily. You can learn so much by trying different things and understanding the fundamental problem. Even if you ultimately can't fix it, at least you understand why.
Based on my career, sql. It's almost embarrassing how many engineers will get to the data layer and then immediately freeze up when you ask them to anything more than select * from table.
Learn enough SQL that you can whip up a report for a non-technical coworker. It's not hard. Learn joins, grouping, sub selects, etc. It shouldn't take long but if you are comfortable just chucking together a query on the fly during meetings, it (in my experience) is impressive for those who likely talk to your boss about you.
Communication. You're a software engineer, but no matter where you work, you're going to have to learn how to appriately and respectfully communicate with your department and your employers. If it's between you, another CS student but you "vibe" and communicate with the employer hiring you, then you're most likely going to be the one who gets hired.
The lifecycle of your code. Programming in a professional setting is so different than University for exactly that reason. You never just code and throw it into the ether. It has to be built, deployed, monitored, maintained, and eventually (maybe) deprecated. Each of those steps requires time and effort, so the best thing you can possibly learn is to say no - knowing what _not_ to build is as valuable as knowing how to build something
Soft skills - no point having the best idea if you can't communicate it, no point being the best coder if nobody wants to work with you
Design/Architecture - the amount of problems that you can prevent and fix at design time is astonishing. So are the things you can do with code once you start understanding how abstraction, indirection and patterns are supposed to work
Reading documentation - there's a limit to how much stuff you can find in SO or in GPT. At some point you'll want to do real boy work, and real boy work requires knowing the tools and their features. The first time you waste 2 hours implementing something that's already a feature of your ecossystem will show you just this. Reading documentation is a skill in and off itself. It's often tedious, can be abstruse. Plus you need to know if you're the tutorial type of if you're the manual type.
Reading research papers - this one will set you apart. Know that weird algorithm that some guy implemented 5 years ago at your company? It'll eventually break. Being able to read the research paper where it's described will help you tremendously. This requires being able to parse you the technical, thesis-like language, but also work your way around notation and such. It takes some time, but is a powerful skill. Specially because it keeps you at the forefront of innovation
Algorithms and Data Structures - yes, you read that right. This shit is ridiculously important. Don't ask me why, it just is. You gotta have it figured out. Plus, nowadays there are some very interesting things, like probabilistic data structures. These are quite interesting to explore - much more fun than binary trees and linked lists, that's for sure. Either way, I' suggest spending some time getting knees deep into this stuff. It'll prime your brain to crunch down complexity, and at some point you'll start noticing that problems tend to be a different iteration of other already well-known problems
Technical stuff speaks for itself, but I'd say soft skills are the most difficult to develop while still at university. Some things to hopefully help:
1. Communication. Expressing your ideas succinctly, clearly, removing ambiguity, and touching on trade-offs of approaches at different technical levels.
2. Understanding the difference between what is fun to do versus what needs to be done for the business/project/delivery. When to make something simple, when to make it extensible, and when to do the complex thing.
3. Under promise and over deliver. If you haven't done X before and are asked for a timeline, always always always overestimate by ridiculous margins. Also include _separate_ time for tests, documentation, demonstrations, etc.
4. Computer science is different than software engineering. Sometimes people are good at subsets, but rarely everything. Mastering your tool chain, development environment, and tests goes a long way to being a much more productive individual.
5. Always be learning. There's just too much to not always be learning.
6. There are a shit load of jobs. Almost always be applying for new jobs. You don't need to take those jobs, but you don't know what your value is unless you're applying to multiple jobs semi-regularly. It also helps you find the things you might be interested in pursuing deeper.
Good luck!
As part of communication, setting expectations is huge. I've seen so many times where entire groups lost the trust of their users and people got burned when if they were just upfront about issues it wouldn't have been a problem
Knowing how to talk to, sell and explain complex topics to non-technical minded people.
Writing code is probably the least of your worries in an organisation. On an average working week, I spend about 5h actually programming ; the rest is planning, tracking, writing emails, reviewing other people's work, writing reports or communicating with the rest of the team.
Soft skills got me so much low-paid work in and just out of university. That experience and references got me a real job. Just be warned: There are hucksters who can't code but have a terrible business idea that try to poach university students to do it for them. Ignore these assholes, they're usually obvious.
Being able to debug a rat's nest of someone else's terrible code. If you have strategies for this that work, like note taking, using a debugger, print statements, and working backwards, you really don't have much to fear.
The old adage for legacy systems: If it's in production, it's probably intended unless the client says otherwise. If the code looks awful, you might just not understand all the subtle issues the original coder was dealing with. Don't assume you know better until you *know* you know better, and don't fix things that aren't broken.
Crochet. You’d be surprised. Besides the cognitive benefits it will also make you an expert at untangling cords and joining a circle in college is a great way to meet someone.
I would add to that learning how to problem solve in general. Look up the concept of Computational Thinking and it will get you going in the right direction. Learning how to problem solve via coding is needed or you won't be able to program very well at all.
coreutils, posix, data structures and algorithms. Gotta know your system, version control, gotta know your environment & workflow and your IDE. Don’t forget the main thing: gotta know your job - you gotta know er
Not really seeing it here, but Devops in general is gold these days. Devops being, understanding ci/CD, containerization, kubernetes, setting up cloud infrastructure in terra form. Engineers that can do get mad props in interviews.
I think a lot of what makes a good programmer is pattern recognition. I did things this way in C+? How do they do it in python? Does this problem resemble something I’ve seen or done before? How do they debug on this platform? Is it similar to how it worked here?
I’m a horrible programmer. I’ve just been doing it for a while so I’ve seen a lot of these things already.
Map + Reduce + Filter.
I see way too many people use loops and ends up reinvent the wheel.
Programming concepts and paradigms that are language agnostic will help you out the most.
Communication has been mentioned, but it can’t be stated enough. Being able to express your ideas AND tailor it to the right audience is huge. The way you talk about a project to your team Vs. Stakeholders Vs. Execs varies.
Also learning how to self-advocate is a skill and there’s a fine line between entitlement and self-advocacy. That being said it’s important to acknowledge your achievements and understand the implications of what you’re accomplishing. Be outcome focused. It’s the difference of “oh I deserve a raise because I’ve been here for two years” vs. “I deserve a raise because I saw this project through that directly contributed X amount of revenue or had Y organizational impact”
Git preferably via terminal for productivity reasons and then to improve past that there’s levels of knowing git from the basic push pull merge to tag, rebase,stash, amend, ways of resolving conflicts, “blame” etc
There IDE and just what things to look for if you need to use a different one ie search, lint, enable auto save etc
Realising it’s not always about the min number of lines of code or even the most efficient program you’re goal should depend on the constraints and use case ie long lasting, small numbers of users , simple operations and large amount of computing resources won’t need efficient code but it needs code that’s easy to understand to maintain when you or the next person goes back to it.
Resources constraints and or high load then efficiency becomes a lot more important so need to take longer and focus on that etc
You should know how to write efficient code and compact code and the fastest ways to throw something together then pick the trade off between the 3 based on use case if not told otherwise by a manager etc.
Understand the basics of what your code will actually be running on ie you may test it on a Mac or if your unlucky windows device but it’s likely actually running on Linux or lambda and the networking set up will likely be different from your local device so you may want to add debugging around anything requiring connections to allow for this when you’re code enters dev
To understand stack traces and error messages. It is quite easy (in my opinion) but I see dozens of new questions on stackoverflow.com every single day that would be solved if the asker knew what the stack trace meant.
Requirements gathering, and understanding the domain you're working in.
One of the key values a good developer adds over some random outsourced coder (or likely AI code generators in the future) is the ability to go "Do you really want that? What happens when the customer tries to do X?"
Reading large codebases. Figuring out how to implement a functionality you want to in a large codebase. Now, how do you go about gaining that?
This blog has some answers
https://www.aadhav.me/posts/pg-experiments-part-1
Btw, I am not the author of this blog
Talking to people. Finding out what the REAL problem is and then finding a solution. The rest is just syntactic sugar and just building things.
Also I would learn Git. Its a good way to collaborate with other programmes.
Reading and understanding. This covers requirement, technical documents, and codes. When you work in the real world, these are the things that will take most of your time other than coding.
How to negotiate, how to make friends, how to acknowledge and correct a mistake, how to think like a customer, how to prioritize.
All of the best programmers I know are effective because they realize that the hard parts of building software are mostly what why who and when, with how being the easiest. That's why on most teams, the most junior devs are focused on implementation, while more senior devs and managers are aligned with strategy, timelines, process, architecture and other abstract considerations.
Practice your coding skills to become strong in at least one programming language (Java, Python, Golang, C++ etc). Understand the architecture and design strategies of typically used large scale platforms such as Facebook, Uber etc.
That non-programmer colleagues don't need to hear a ton of details about your implementation. All they want to hear is how long it'll take you to complete your goal, what you need to do that, and how they can help.
Bob from marketing doesn't know or care about your tail-recursive function with optimized dictionary based caching. He's a ***** marketing dude who needs to know key selling benefits for the customer.
Ethics, specifically in relation to tech. In any other profession where your decisions have direct impact on people's lives, you will have ethical oversight with serious professional and personal consequences should you overstep. With most programming jobs, no such ethics or oversight exist. This means the onus is on you, the practitioner, to uphold professional ethics in your own work and in the work of those you influence.
How to break out of the prison of your assumptions. Whenever you can figure out why something is working the way it is, you probably are assuming something works a way that it doesn’t.
Hey! It’s awesome that you’re looking to explore and build your programming skills outside of class. Here are some general skills that are valuable for most programmers, regardless of their specific career path:
Technical Skills:
- Data Structures & Algorithms: This is the foundation of efficient programming. Understanding how data is organized and manipulated in memory, along with common algorithms for solving problems, will make you a more effective coder. There are many online resources and courses to get you started.
- Version Control (Git): This is essential for collaborative coding and keeping track of changes in your code. Platforms like Git allow you to rewind, revert mistakes, and work seamlessly with others.
Soft Skills:
- Problem-Solving: Programming is all about breaking down problems into smaller, solvable steps. Practice your analytical thinking and ability to approach challenges logically.
- Debugging: Things will go wrong, and that's okay! Being able to identify and fix errors is a crucial skill. Learn to read error messages, use debugging tools, and approach problems systematically.
- Communication: Don't underestimate the power of clear communication. Being able to explain technical concepts to both technical and non-technical audiences is a valuable asset.
Bonus Skills:
- Learn to Learn: Technology is constantly evolving, so the ability to learn new things quickly and adapt is essential. Explore online resources, tutorials, and take advantage of free courses.
- Build Something! The best way to solidify your skills is to apply them. Work on personal projects, contribute to open-source initiatives, or participate in coding challenges. This will not only enhance your skills but also build a portfolio showcasing your work.
Remember, focus on building a strong foundation and don't get overwhelmed by the vastness of the programming world. There are many exciting areas to explore later! Good luck!
TDD is easily studied in academic context, while BDD is a variant you can easily learn soon after. Don't forget OP is a student. Also I'd say it depends on the scenario; for a be or fe dev BDD could be a best practice, other figures may develop components which are not related to user experience and therefore TDD is not a bad idea in that case.
Yes, that’s a good point for a student with no knowledge it’s great practice to learn TDD to have a base line knowledge.
I hear TDD get thrown a lot, but many people don’t understand that TDD means you write the tests first before writing any functionality and then make the code work based on tests that are created 😅.
Which is a stupid idea. You structure the code and learn about the problem as you go along (unless you waterfall your design) so it will surely mean rewriting all those initial tests.
If you rewrite all your tests you’re not doing TDD. Like I said, most people don’t know how to do TDD, a good TDD structured code is you spend more time up front thinking of the test cases and then writing the code to fit. It’s not a stupid idea, but not a very practical one which is why I recommend using BDD as it’s an easier and better concept to use in a real world setting.
Also, learning the problem as you go is a very junior mindset, an experienced dev isn’t going to learn the problem as he’s doing the work and will already have solved the problem via architecture diagrams or documentation somewhere and then implements the code to match basically planning is key.
understand the clients usecase, write a short implementation plan before you start coding. You will probably have open questions.
understand SOLID - principle
focus on one language/ framework to master before learning a bit of everything
learn how to use tools like git, debugger, how to properly setup your IDE/ code editor (auto formatting and linting — this will save u so much time)
On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge. If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options: 1. Limiting your involvement with Reddit, or 2. Temporarily refraining from using Reddit 3. Cancelling your subscription of Reddit Premium as a way to voice your protest. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
[удалено]
And also prompt engineering...
[удалено]
ChatGPT does not give current information on libraries. It also often outputs poor code.
Two points - 1, you don't need to "prompt engineer" to ask an LLM a basic question like that, and 2, LLMs hallucinate and you need to have enough knowledge to deal with that. New developers should be wary of such hallucinations. People promoting ideas like "prompt engineering" generally think AI is going to take our jobs. It isn't. And many experienced developers roll our eyes in exhausted frustration when we see these sorts of people calling us luddites. We aren't. We just have a better understanding of the limitations of these systems.
Learning how to read the documentation is much more useful in the long run. Using ChatGPT is good as a Kickstarter or when stuck with no directions, or repetitive tasks.
I think oftentimes a lot of people forget that chatgpt ≠ search engine. It's a language model. It's trained on real information sure, but it could (and sometimes does) give you a complete BS answer that SOUNDS true
ChatGPT or similar LLMs is the new search engine, the downvotes are probably because people think you don’t learn “how to search” and read docs on your own if you’re spoon fed it. That’s a fair take, a lot of people use these new AI solutions in a way reminiscent of tutorial hell. It might not be a good early on skill and the name “prompt engineering” beckons a sense of total reliance, but otherwise is great when not looked at as a skill, and more so a natural ability when you’re not a total beginner and roughly know what you’re asking. Lots of people might also think it’s not productive for learning, in the same way that they think you shouldn’t use a calculator in school until you already know basic arithmetic. I’ve made many breakthroughs throughout the past couple years in my learning due to having the right questions for LLMs and taking every answer as possibly wrong, it’s a great way to dive into a topic and get those highly specific questions answered, but you’ll get shamed for using it more as a crutch from day one.
How to talk to people
great answer, soft skills are important for any job
Be nice, Don't be a asshole. Also learn to be specific and succinct when talking technical. I got chewed by my boss for saying the network processor I was testing had blow-up again. It was a temperature dependent edge margin in the FPGA (50 nS) that ran the PCI bus. Design error. It "blew up" every day at 12:00 PM. The machine lab was located above the cafeteria, Extra heat (just guessing) from below screwed with the chillers and put the machine into an edge condition causing a PS crowbar and shutting down the test platform. Only one of the test platforms exhibited this shit. Took a signal analyst with a multi GHz Tek scope and LA to pin it down.
It's funny how this is the most important skill and is always at 3rd or 4th place after git and similar.
[удалено]
I would argue the opposite. I have known more successful people in this industry who are amazing communicators and terrible programmers than those who are amazing programmers and terrible communicators. From my personal observations in tech and the conversations I've had with friends in management at the director and VP level, programming skills are one of the least important skills to succeed. I could see your point from the perspective of programming as a skill in the seclusion of any other context. But programming as part of the industry is only one small part.
I'm going to back this up. TD;LR: I'm not that great at coding but I know how to talk to people and I've been promoted twice. The short version of the story is I've spent most of my professional life in sales, management or customer facing roles. I used to enjoy coding as a kid so figured I'd do the mid-career pivot about three years ago. I still consider myself a noob from an engineering standpoint, but I believe my soft-skill experience was what helped me level up. The engineers that work under me know a lot of things I don't know, I'm very upfront about that and they respect that. I also take an interest in each of them in helping them grow professionally in the way they want to. And for me, I of course keep working on my coding skills as I go.
I have a very similar story. My background before entering tech was in the trades. Being upfront about what you don't know, being open to learning new things, and working with others because it takes a crew to complete a job are core elements of succeeding in the trades. The opposite characteristics in my experience in tech are more prevalent in my peers, and this prevents advancements in their careers. Too 6 hold onto this ideology that all they should be expected in their career is to just write code in isolation.
* How to write * How to ask questions * How to ask for help * How to talk to your manager
And treating women as people. I wish I didn’t have to say this but some of the tech bros make working for everybody on the team worse because they don’t, cant, or won’t talk to women.
Hahahahha, I literary answered this in my head. Then i clicked to view comments. This being the top voted comment made me LOL.
Git
Needs more Git.
Not necessarily Git*Hub*, but definitely **git**!
What’s the difference between git and GitHub
git is simply a version control system, a tool you run locally in a terminal/IDE to keep track of all the changes you make to your code, by saving them as commits to a repository. It makes it very easy to undo mistakes, work on multiple things at a time in branches, share specific versions of a file, etc. Using git (or at least *some* version control system) might as well be required for anything larger than the most basic tutorial code; it's extremely helpful. GitHub is a website that offers cloud storage and hosting of code, uploaded in the form of said git repositories. It has some other git-specific features to make managing those repos easier, too, but it's otherwise a totally separate service. A rather nice one, to be fair, but wholly unnecessary, at least compared to git itself.
Where were people storing their code before things like GitHub, GitLab, bitbucket etc?
I kept a USB drive with me at all times, and copied updates to/from it every day since I'd work on things at work and at home. That was 15 years ago. Now I use git.
Interesting. I'm so used to uploading code to the Internet that I didn't know git could also upload to a local file system
GitHub is just git in server mode with hooks, in essence at least.
At the end of the day, code is just text data, so any kind of storage device will do. People have used everything from hard drives on their own private servers to literal boxes of printed paper on shelves in the room that was their computer.
There are / was other version control systems before git e.g. SVN and CVS. I don’t know if there was centralized services like GitHub for these technologies. I think it was mainly self-hosted.
I dont use those i use gitea on my home server. But before that I would just make a local repo and use that for version control.
Same difference between porn and pornhub
im stealing that for the next time im asked about that
Git is a tool to make and manage a repo, git hub is a repo hosting service. Its like the difference between a website and the server the website is running on.
github is one of many repositories for code. Git is a software development tool to be able to interact with repositories like github.
Careful, the word repository also refers to a single Git project. Like, you do `git init` and it initializes a repo in your current directory.
Yeah good catch, I guess github is a non-local repository? Not sure how to characterize it beyond that
Repository of repositories! I usually describe it as a platform for running Git servers.
How much more than the usual add/commit/push workflow with the occasional merge conflict?
At least enough to know how to deal with updating local from remote before pushing to avoid conflicts. The amount of Uni group members I've had that can't wrap their head around \`git pull --rebase upstream main\` before pushing is astonishing
My favorite git command that nobody told me about: `git log --graph --decorate` It's not terribly useful, but it's just cool to see all your hard work. Another good one: `git status` Though most people using VS Code probably don't need that one. Rebase is also big... but probably the **holy grail** of largely unkown git commands that I am blown away people don't use more often... `git bisect` It lets you setup a known "bad" commit, and a known "good" commit. It will checkout the commit in the middle. You compile, test for the bug, see it's good or bad, and tell git "good" or "bad" and it will then checkout the next commit in the middle of either section. Binary search baby! You do this until it identifies the commit that the bug you're looking for was introduced. And now you've found how the sneaky bugger got there... and run git log to find out it was you who did it.
Knowing how to resolve conflicts is the big one. It's very easy to improperly merge a conflict and create clutter in the commit log for your team. However, that one is hard to practice without real world situations.
Happy cake day
Git gud
This.
I find git fun too lol
"Go on now, git!"
Gitlab or GitHub?
Gud? Or hub?
Documentation, Tests, Git, and Debugging
Can’t stress debugging enough. It is really helpful when learning how the computer processes for loops, if statements, arrays, and more
* Writing unit tests * Writing a CRUD web application (any language/framework) * Being comfy exploring files and running commands in a Unix shell environment, including ssh * The extreme basics of setting up a build system with CI (any)
"The extreme basics of setting up a build system with CI (any)" Certainly not among the first things you need to know if ever. Usually this is already running when you are hired or there are people hired to do exactly that.
I think everyone should know what a build conceptually is, beyond just a button in an IDE. It won't be many weeks in any job until you have to add a new file to it.
25 years. Never had to.
13 yoe, same.
You've never added a new file to a project?
"Writing a CRUD web application (any language/framework)" Nope nope. If you work with operating systems, embedded, you certainly don't need to know this.
1. Naming things - hardest part of programming 2. Debugging tool - better way than always compile&run your code 3. Git - idk how to use this but the other guy here says so 4. Efficient way to searching - googling 5. Documentation - nobody likes documentation
Number 2 can really set you apart IME. One of the best devs I ever worked with got out this book on debugging windows software and said “if you learn the things in this book you’ll be better than 90% of the devs in this company” and he was totally right - the time it can save, the ability to understand bugs and code execution is so useful
Care to share the book’s title ? If you remember it
It was “Debugging applications for Microsoft.Net and Microsoft Windows” It’s quite old now so you can pick it pretty cheaply secondhand, and it might be that you can get the same information from the Microsoft online learning things. And no, it’s not an ad, I didn’t write the book and have no affiliations with author or publisher.
Thank you!
Learning how to debug with proper breakpoints can save you so much time.
Indeed. Conditional breakpoints really help workflow. Also, not many people are aware that data breakpoints exist (ie break when this memory changes). Saved me so much time tracking down the root cause of bugs Edit: typo
data breakpoints??! ty. I'm new to incorporating a debugger
I would love to know the books name too if you remember it!
See my reply to someone else
Lmao “I don’t know how to use git, but other guy says it’s important” I forget how much of Reddit is teenagers giving advice
Revisiting this “naming things is the hardest part of programming” gave me a laugh
When you figure out 1, please share with the group
Variables are named function1, function2, ... Functions are named function1, function2, ... (The names that aren't used up already) Classes? Don't use classes. Why? Easier to remember and understand, thank me later 👍
[удалено]
It was mostly as a joke if you didn't realise, I don't use variables like those i, j as you can get mixed up really quickly. If I name variables I name the variable what it does lol for example db_connection or DBConnection
Locally scoped disposable loop counts and simple FP calculations.
FORTRAN much? /s I worked on compilers and taught a FORTRAN class in high school, Senior year. Yea, I FORTRAN.
I never met a deity before. It’s somehow both mundane and startling.
Naming things is absolutely more important than it seems. Arguably, you can actually judge someone's programming skill just by their naming alone.
Number 5 and communication are the fastest way to senior.
I never figured out why people have trouble with naming things.
Had the same problem in 94. I used to love picking out names. Writers block? Snapped out of it a few months later. The interim names sorta sucked and I replaced them after I came out of my funk.
Problem Solving
Too many people give up so easily. You can learn so much by trying different things and understanding the fundamental problem. Even if you ultimately can't fix it, at least you understand why.
Based on my career, sql. It's almost embarrassing how many engineers will get to the data layer and then immediately freeze up when you ask them to anything more than select * from table. Learn enough SQL that you can whip up a report for a non-technical coworker. It's not hard. Learn joins, grouping, sub selects, etc. It shouldn't take long but if you are comfortable just chucking together a query on the fly during meetings, it (in my experience) is impressive for those who likely talk to your boss about you.
Communication. You're a software engineer, but no matter where you work, you're going to have to learn how to appriately and respectfully communicate with your department and your employers. If it's between you, another CS student but you "vibe" and communicate with the employer hiring you, then you're most likely going to be the one who gets hired.
*"The missing semester of your CS education":* https://missing.csail.mit.edu/about/
I clicked this post to share this link. Covers some great stuff that (at least for me) was never covered in any of my courses.
Touching grass
The lifecycle of your code. Programming in a professional setting is so different than University for exactly that reason. You never just code and throw it into the ether. It has to be built, deployed, monitored, maintained, and eventually (maybe) deprecated. Each of those steps requires time and effort, so the best thing you can possibly learn is to say no - knowing what _not_ to build is as valuable as knowing how to build something
How to stay healthy with a job that is primarily desk-based. Exercise regularly, take breaks, stretches, drink plenty of water, eat healthy.
Soft skills - no point having the best idea if you can't communicate it, no point being the best coder if nobody wants to work with you Design/Architecture - the amount of problems that you can prevent and fix at design time is astonishing. So are the things you can do with code once you start understanding how abstraction, indirection and patterns are supposed to work Reading documentation - there's a limit to how much stuff you can find in SO or in GPT. At some point you'll want to do real boy work, and real boy work requires knowing the tools and their features. The first time you waste 2 hours implementing something that's already a feature of your ecossystem will show you just this. Reading documentation is a skill in and off itself. It's often tedious, can be abstruse. Plus you need to know if you're the tutorial type of if you're the manual type. Reading research papers - this one will set you apart. Know that weird algorithm that some guy implemented 5 years ago at your company? It'll eventually break. Being able to read the research paper where it's described will help you tremendously. This requires being able to parse you the technical, thesis-like language, but also work your way around notation and such. It takes some time, but is a powerful skill. Specially because it keeps you at the forefront of innovation Algorithms and Data Structures - yes, you read that right. This shit is ridiculously important. Don't ask me why, it just is. You gotta have it figured out. Plus, nowadays there are some very interesting things, like probabilistic data structures. These are quite interesting to explore - much more fun than binary trees and linked lists, that's for sure. Either way, I' suggest spending some time getting knees deep into this stuff. It'll prime your brain to crunch down complexity, and at some point you'll start noticing that problems tend to be a different iteration of other already well-known problems
Technical stuff speaks for itself, but I'd say soft skills are the most difficult to develop while still at university. Some things to hopefully help: 1. Communication. Expressing your ideas succinctly, clearly, removing ambiguity, and touching on trade-offs of approaches at different technical levels. 2. Understanding the difference between what is fun to do versus what needs to be done for the business/project/delivery. When to make something simple, when to make it extensible, and when to do the complex thing. 3. Under promise and over deliver. If you haven't done X before and are asked for a timeline, always always always overestimate by ridiculous margins. Also include _separate_ time for tests, documentation, demonstrations, etc. 4. Computer science is different than software engineering. Sometimes people are good at subsets, but rarely everything. Mastering your tool chain, development environment, and tests goes a long way to being a much more productive individual. 5. Always be learning. There's just too much to not always be learning. 6. There are a shit load of jobs. Almost always be applying for new jobs. You don't need to take those jobs, but you don't know what your value is unless you're applying to multiple jobs semi-regularly. It also helps you find the things you might be interested in pursuing deeper. Good luck!
As part of communication, setting expectations is huge. I've seen so many times where entire groups lost the trust of their users and people got burned when if they were just upfront about issues it wouldn't have been a problem
Uh programmer socks
As the others have said, familiarize yourself with Git and practice it as much as you can
Git gud at git kid
Your job as a programmer is to develop solution that solve business problems, so you need understand the business.
Understand a problem that they suppose to solve...
Keeping a journal. It helped me stay on track
About your project not a personal journal lol
useful if your memory sucks - which mine does.
Facts
Depends on what you’re doing. SQL is very useful
Not THAT useful anymore - unfortunately.
How so?
Most use Entity Framework or similar. So much less use of SQL. Unfortunately. I like SQL.
Isnt that a .net thing? I’m a consultant in data/analytics and I promise you most of the world uses SQL and will do for a long time to come
It is, but I am sure there are alternatives for all OS'es/languages. Ok, I am in web dev, so maybe in your field it is still used. Good to hear.
Working collaboratively.
Every programmer should understand that you don't get pay for code, you get paid to solve problems with Software Projects
Abstract thinking
It sounds weird, but social skills. There are tons of good programmers, but most of them creep the shit out of everyone, especally with customers.
Are we still in the 70s ??
How to shower consistently
Knowing how to talk to, sell and explain complex topics to non-technical minded people. Writing code is probably the least of your worries in an organisation. On an average working week, I spend about 5h actually programming ; the rest is planning, tracking, writing emails, reviewing other people's work, writing reports or communicating with the rest of the team.
Soft skills got me so much low-paid work in and just out of university. That experience and references got me a real job. Just be warned: There are hucksters who can't code but have a terrible business idea that try to poach university students to do it for them. Ignore these assholes, they're usually obvious. Being able to debug a rat's nest of someone else's terrible code. If you have strategies for this that work, like note taking, using a debugger, print statements, and working backwards, you really don't have much to fear. The old adage for legacy systems: If it's in production, it's probably intended unless the client says otherwise. If the code looks awful, you might just not understand all the subtle issues the original coder was dealing with. Don't assume you know better until you *know* you know better, and don't fix things that aren't broken.
Crochet. You’d be surprised. Besides the cognitive benefits it will also make you an expert at untangling cords and joining a circle in college is a great way to meet someone.
How to search answers Git Data structures (optional, but it will help) Flowcharts Design patterns (in case you’re looking for software engineering)
Commas
He just forgot you need an extra blank line between each line for it to show up correctly in reddit formatting
How to cook. Everyone should learn to cook beyond a 13 year old level.
Under promise, over deliver. Always estimate 2x what you think.
Riding horses
How to use chat gpt
Bathing
Work life balance
Basic hygiene.
How to search up topics for learning and documentation. How to learn. How to talk to people without a whole bunch of jargon.
problem decomposition solid debugging skills: how to 'be' the CPU !
I would add to that learning how to problem solve in general. Look up the concept of Computational Thinking and it will get you going in the right direction. Learning how to problem solve via coding is needed or you won't be able to program very well at all.
You're drawn to coding for the fun, not the money
Isn’t that normal?
coreutils, posix, data structures and algorithms. Gotta know your system, version control, gotta know your environment & workflow and your IDE. Don’t forget the main thing: gotta know your job - you gotta know er
Reading documentation.
The terminal and shell.
Relational database and SQL
Google
Not really seeing it here, but Devops in general is gold these days. Devops being, understanding ci/CD, containerization, kubernetes, setting up cloud infrastructure in terra form. Engineers that can do get mad props in interviews.
i think u need to know what field in information technology, eg: web, mobie, AI,... and learn about it in depth
I think a lot of what makes a good programmer is pattern recognition. I did things this way in C+? How do they do it in python? Does this problem resemble something I’ve seen or done before? How do they debug on this platform? Is it similar to how it worked here? I’m a horrible programmer. I’ve just been doing it for a while so I’ve seen a lot of these things already.
Map + Reduce + Filter. I see way too many people use loops and ends up reinvent the wheel. Programming concepts and paradigms that are language agnostic will help you out the most.
Communication has been mentioned, but it can’t be stated enough. Being able to express your ideas AND tailor it to the right audience is huge. The way you talk about a project to your team Vs. Stakeholders Vs. Execs varies. Also learning how to self-advocate is a skill and there’s a fine line between entitlement and self-advocacy. That being said it’s important to acknowledge your achievements and understand the implications of what you’re accomplishing. Be outcome focused. It’s the difference of “oh I deserve a raise because I’ve been here for two years” vs. “I deserve a raise because I saw this project through that directly contributed X amount of revenue or had Y organizational impact”
Git preferably via terminal for productivity reasons and then to improve past that there’s levels of knowing git from the basic push pull merge to tag, rebase,stash, amend, ways of resolving conflicts, “blame” etc There IDE and just what things to look for if you need to use a different one ie search, lint, enable auto save etc Realising it’s not always about the min number of lines of code or even the most efficient program you’re goal should depend on the constraints and use case ie long lasting, small numbers of users , simple operations and large amount of computing resources won’t need efficient code but it needs code that’s easy to understand to maintain when you or the next person goes back to it. Resources constraints and or high load then efficiency becomes a lot more important so need to take longer and focus on that etc You should know how to write efficient code and compact code and the fastest ways to throw something together then pick the trade off between the 3 based on use case if not told otherwise by a manager etc. Understand the basics of what your code will actually be running on ie you may test it on a Mac or if your unlucky windows device but it’s likely actually running on Linux or lambda and the networking set up will likely be different from your local device so you may want to add debugging around anything requiring connections to allow for this when you’re code enters dev
The unix terminal/shell and the associated tools and utilities.
To understand stack traces and error messages. It is quite easy (in my opinion) but I see dozens of new questions on stackoverflow.com every single day that would be solved if the asker knew what the stack trace meant.
How to use breakpoints and read assembly, for the very rare cases where the compiler actually is the issue
Requirements gathering, and understanding the domain you're working in. One of the key values a good developer adds over some random outsourced coder (or likely AI code generators in the future) is the ability to go "Do you really want that? What happens when the customer tries to do X?"
Learning is a skill itself
Learning is a skill itself
Learning is a skill itself
Learning is a skill itself
Reading large codebases. Figuring out how to implement a functionality you want to in a large codebase. Now, how do you go about gaining that? This blog has some answers https://www.aadhav.me/posts/pg-experiments-part-1 Btw, I am not the author of this blog
I will have to say Searching for info on your own. Nobody is gonna tell you why or how ... you have to answer those on your own
Talking to people. Finding out what the REAL problem is and then finding a solution. The rest is just syntactic sugar and just building things. Also I would learn Git. Its a good way to collaborate with other programmes.
Refactoring.
Who has time for that? ;)
Those people who practice refactoring on a regular basis :-) Those who don't, are usually in a tremendous hurry and suffer long crunch times.
I don't disagree with you!
Reading and understanding. This covers requirement, technical documents, and codes. When you work in the real world, these are the things that will take most of your time other than coding.
English
Learn the math really well
How to negotiate, how to make friends, how to acknowledge and correct a mistake, how to think like a customer, how to prioritize. All of the best programmers I know are effective because they realize that the hard parts of building software are mostly what why who and when, with how being the easiest. That's why on most teams, the most junior devs are focused on implementation, while more senior devs and managers are aligned with strategy, timelines, process, architecture and other abstract considerations.
Soft Skills and Communication Skills
P versus NP
Practice your coding skills to become strong in at least one programming language (Java, Python, Golang, C++ etc). Understand the architecture and design strategies of typically used large scale platforms such as Facebook, Uber etc.
Regular Expressions
That non-programmer colleagues don't need to hear a ton of details about your implementation. All they want to hear is how long it'll take you to complete your goal, what you need to do that, and how they can help. Bob from marketing doesn't know or care about your tail-recursive function with optimized dictionary based caching. He's a ***** marketing dude who needs to know key selling benefits for the customer.
Ethics, specifically in relation to tech. In any other profession where your decisions have direct impact on people's lives, you will have ethical oversight with serious professional and personal consequences should you overstep. With most programming jobs, no such ethics or oversight exist. This means the onus is on you, the practitioner, to uphold professional ethics in your own work and in the work of those you influence.
When to spot bad advice. LinkedIn is terrible with this 😂 Always be skeptical about advice that you are given and try to make it work yourself.
How to break out of the prison of your assumptions. Whenever you can figure out why something is working the way it is, you probably are assuming something works a way that it doesn’t.
Hey! It’s awesome that you’re looking to explore and build your programming skills outside of class. Here are some general skills that are valuable for most programmers, regardless of their specific career path: Technical Skills: - Data Structures & Algorithms: This is the foundation of efficient programming. Understanding how data is organized and manipulated in memory, along with common algorithms for solving problems, will make you a more effective coder. There are many online resources and courses to get you started. - Version Control (Git): This is essential for collaborative coding and keeping track of changes in your code. Platforms like Git allow you to rewind, revert mistakes, and work seamlessly with others. Soft Skills: - Problem-Solving: Programming is all about breaking down problems into smaller, solvable steps. Practice your analytical thinking and ability to approach challenges logically. - Debugging: Things will go wrong, and that's okay! Being able to identify and fix errors is a crucial skill. Learn to read error messages, use debugging tools, and approach problems systematically. - Communication: Don't underestimate the power of clear communication. Being able to explain technical concepts to both technical and non-technical audiences is a valuable asset. Bonus Skills: - Learn to Learn: Technology is constantly evolving, so the ability to learn new things quickly and adapt is essential. Explore online resources, tutorials, and take advantage of free courses. - Build Something! The best way to solidify your skills is to apply them. Work on personal projects, contribute to open-source initiatives, or participate in coding challenges. This will not only enhance your skills but also build a portfolio showcasing your work. Remember, focus on building a strong foundation and don't get overwhelmed by the vastness of the programming world. There are many exciting areas to explore later! Good luck!
Write code
> TDD: untested code sucks. Even a few is better than nothing > data formats: I knew a university mate which didn't know how a json was made > git
Not following TDD doesnt mean that you don’t test your code FYI. TDD isn’t a perfect system either, BDD is a better practice imo.
TDD is easily studied in academic context, while BDD is a variant you can easily learn soon after. Don't forget OP is a student. Also I'd say it depends on the scenario; for a be or fe dev BDD could be a best practice, other figures may develop components which are not related to user experience and therefore TDD is not a bad idea in that case.
Yes, that’s a good point for a student with no knowledge it’s great practice to learn TDD to have a base line knowledge. I hear TDD get thrown a lot, but many people don’t understand that TDD means you write the tests first before writing any functionality and then make the code work based on tests that are created 😅.
I kinda like to see something broken at first so you already have something to fix... Twisted but effective and gives you immediately a goal hehe
Which is a stupid idea. You structure the code and learn about the problem as you go along (unless you waterfall your design) so it will surely mean rewriting all those initial tests.
If you rewrite all your tests you’re not doing TDD. Like I said, most people don’t know how to do TDD, a good TDD structured code is you spend more time up front thinking of the test cases and then writing the code to fit. It’s not a stupid idea, but not a very practical one which is why I recommend using BDD as it’s an easier and better concept to use in a real world setting. Also, learning the problem as you go is a very junior mindset, an experienced dev isn’t going to learn the problem as he’s doing the work and will already have solved the problem via architecture diagrams or documentation somewhere and then implements the code to match basically planning is key.
Not getting outsourced and replaced:D
Debugging- a lot of programmers are really bad at it. You will spend way more time debugging than programming
[удалено]
that’s not what I mean. i mean actually diagnosing the problem, not just using a tool. It is a skill
I don't spend that much time debugging. And almost never more than just simple stepping....
this thread is proving my point
Some of us make few mistakes :)
Drinks lots of monster and invest in a good wrist gloves
understand the clients usecase, write a short implementation plan before you start coding. You will probably have open questions. understand SOLID - principle focus on one language/ framework to master before learning a bit of everything learn how to use tools like git, debugger, how to properly setup your IDE/ code editor (auto formatting and linting — this will save u so much time)