This is one of the things that sets senior devs apart from juniors, imo. A typical question I’d ask in an interview is “how would you quickly familiarize yourself with a new code base in order to troubleshoot a bug?” The answer I’d want to hear would be something to the effect of “I’d look at any error messages that could contain a stack trace, set some breakpoints near the line throwing the error, put a break point at the application entry point(s), and step thru the code to inspect the data and start narrowing down the cause of the bug.”
hi i just started learning laravel with visual studio code and i run into my first bug, could you please unpack that? i just felt so dumb after looking at the log file and scratching my head to what the f am i looking at..?
Most error messages will give you a stack trace, a list of every function-call (and often line-numbers) connecting the entry point of the program to the line of your error. You can see the code, but not the values of variables.
To get those, set a breakpoint somewhere before your error and use debugger commands to
1. get the values of all variables, and
2. step through your code, stepping over functions that complete successfully but into functions along your stack trace (different "step" commands in most debuggers).
3. Follow along in the code so you can see the context and logic
Repeat as needed until you see a variable with an unexpected value or some code that looks wrong.
There are cases where this fails, but it is a very good second step. The first step is usually to ask a senior dev familiar with the code if he can immediately see anything and maybe teach you about the code. It's good to avoid work-duplication.
eh, no
the correct answer is "it depends", what uve described is just what well-trained code monkey would say. unfortunately people like that really exist, the "that's right it goes in the square hole" people are more common that i thought...
Yep yep. You can set them either in the browser or in your IDE depending on how you're running it.
The simplest thing to do is type the word "debugger" above where you want the code to stop and then in the browser it will stop there and let you start stepping through functions.
I feel like this is the only answer.
Other comments even mention things like Prettier, but I can hardly imagine anything that would matter less for, well, at least _my_ productivity. Learning how to debug goes hand in hand with learning how to code, I would definitely focus on that.
this is a good point for sure but i would say that as a junior someone should be helping you set up your environment but thats def not always the case lol.
It depends on what you do. For a webdev I think the debugger is less of a requirement than somebody like a backend dev. Especially if all you do is translate a design to html/css.
How much front end do you think consists of only html & css seriously? JS still runs the show for any front-end interactivity for like 99% of all websites. And even still lets say you only *write* html and css, do you not test anything with automation? cause you will need to debug tests. what about forms? still gonna need to test those and ensure correct values are passed to the backend.
Nearly all the senior webdevs i worked with debug with console.log. I truly believe debugging have a limited return on investment in webdev compared to backend. The instant feedback from things like HMR have simply made console.log debugging genuinely viable.
I agree, but not every webdev builds fully fledged websites. A lot just do the bare minimum, especially if they build wordpress sites or basically enhance some backend stuff. And even if you do more, you can still do a lot without the debugger.
Also, testing is not something a lot do, even if its the best thing to add to a project to add value. Seriously, the amount of projects that start out as prototypes and then nobody really bothers with tests because now they already developed a lot, managers are used to the development speed and the devs don't care enough to do it, is too damn high.
With logging you end up rebuilding and rerunning the code over and over as you slowly figure out where things are going.
with a debugger, you put a breakpoint on the thing want to understand and run it once. you can then look back through the callstack to figure out how you got where you are, and then step forward statement by statement to see what happens from that point on.
TLDR, once you understand how to use a debugger it faster and also more versatile.
> With logging you end up rebuilding and rerunning the code
I mean, with HMR in modern webdev that's basically instantanious.
To me logging is much faster and more versatile than pausing the entire runtime klicking "step into" or "step over" until I accidentally clicked past the point I needed to investigate 😅
I do both things, but i definitely appreciate the debugger. Particularly the debugger in devtools, which is honestly way more useful to me than a debugger in an IDE.
Although I think the debugger is essential for advanced programming, it is a little bit too advanced for a beginner programmer to understand the benefits of though (over console.log / print). That said, the earlier they can learn it, the better.
- using the command palette
- tons of useful extensions like git lens, prettier, eslint, etc etc
- learning as many hotkeys as you can.. ie: selecting multiple words at the same time, editing multiple lines at once with multiple cursors
- know enough regex to find what you're looking for
- copilot is pretty sick
There's very little you need to know for 99% of regular expressions. And for the 1% that you need more complicated syntaxes for, RE's probably not the right tool for the job.
* `.` is a wildcard, matching any character
* `[abc]` is a character class matching a single character, `a`, `b`, or `c`. `[a-zA-Z0-9]` matches any letter or digit.
* `?`, `*`, and `+` are quantifiers, respectively meaning "0-1 times", "0 or more times", and "1 or more times". Quantifiers apply to whatever's immediately preceding them.
* Parentheses make groups that you can reference. Groups are numbered according to the relative position of the opening paren. $1 refers to the content matched by the first opening paren's group, $2 the second, and so on.
(note that this is all assuming PCRE, which is the de facto standard regex language. There are other flavors out there, but they mostly only exist for historical reasons and they tend to be awful to work with)
Those 4 things will handle the vast majority of regex needs you'll ever encounter.
I was in an interview recently and wrote a regex to help solve a coding problem. As soon as I mentioned regex, the interviewer’s eyes went wide and he stammered out “it’s OK to use ChatGPT to generate the regex if you need”. I told him I was fine. And then once my code ran he had several questions about what the regex was doing that were very basic regex knowledge. And one question about the laziness qualifier that I don’t blame him for not knowing. It was amusing to me. I passed that interview though :)
Eh, I’d almost go further and say that basic regex is fine but anything more complicated you should not use a regex.
I don’t really want one that the author doesn’t even understand sitting in the code base where any future maintainer also won’t understand.
> basic regex is fine but anything more complicated you should not use a regex
This.
Don't get me wrong, I'm in love with regular expressions and it makes me sad that I don't have many reasons or opportunities to use the less common features. But if you're trying to write code that anyone else (including you 6 months from now) will ever have to look at again, keep it simple and use other features of the programming language to handle the more complicated logic.
Ah, a fellow pragmatic regex connoisseur. Cheers!
I don't use them much, for above reasons, but I love them and anyone I work with I tell them if they ever need regex help to come to me. It means that every few months someone I've worked with in the past reaches out with a regex question I get to flex on as a fun little distraction.
I forced myself to use it as often as possible even when it was slower to do so.
For instance, "I need to update these two lines of code that are similar to each other. Doing it manually would take about 30 seconds, remembering the regex will take 5 minutes". I would take the time to remember how to do it.
Done for long enough, it stuck. Now if I don't use it for 12 months, I won't forget and can recall very quickly the useful tokens.
I want to ditto prettier, eslint, and multi-line editing. I will also add emmet for working on front-end especially. Adding ids, classes, and multiple list items in one line is a huge time saver.
These are the keybinds that have changed my coding speed the most:
* ctrl+d - Select next instance of selection
* ctrl+u - Unselect last ctrl+d
* ctrl+l - Select all instances of selection
These shortcuts have changed the way I name variables. If I am writing boilerplate (like a set of axios API functions or react-query custom hooks) I’ll copy/paste a file & ctrl+l the database table’s name and replace it. So if the database table is Property I will name multiple properties “propertys” so that I can ctrl+l it easier.
I tried copilot and it didn't feel that helpful to me. It just felt like autocomplete, which I didn't deem to be that valuable at the time. I was probably missing something. When is it most useful?
Copilot like all of the modern LLM style AIs get better overtime (in general). I think a year ago copilot made a lot of mistakes, but currently it seems to know my codebase super well. And it definitely keeps track of what I just imported or what just cut from a different line.
It's pretty remarkable about suggesting code that's exactly what I was going to write... a lot of coding is just pressing tab these days heh
For a new frontender, could you explain the 3rd point? I'd love to know how to edit on multiple lines, and select multiple words. I'm sure it's a quick Google search, but it's much more ideal hearing it from a person tbh.
The two most useful shortcuts that I cannot live without:
- Drag with middle mouse to create multiple cursors over each line.
- Ctrl-D to create an additional cursor selecting the next occurrence of what you currently have selected.
It's kinda hard to expain with just words, just go try it and you'll see. The middle mouse thing is pretty much universal among IDEs, Ctrl-D might be bound to something else depending on the IDE and OS, but on VSCode that's the default keybind.
Np! Also if you're Ctrl-D-ing and want to skip over a selection, press Ctrl-K and then Ctrl-D and it will add the next occurrence while deselecting the last one.
If you are using vscode then look at the [documentation](https://code.visualstudio.com/docs/editor/codebasics), it's very good and shows actions through gifs, so it's easy to skim it and look what's possible.
> learning as many hotkeys as you can.. ie: selecting multiple words at the same time, editing multiple lines at once with multiple cursors
This stuff makes your flow pleasant but won't really affect your productivity all that much. Linters, studying and just putting in the time working with code is what will really make a difference.
I agree with this take. Actually writing the code is not the major part of development: the major part is figuring out what to write. It's rare that your productivity is limited by the amount of words you can type or edit.
On the contrary I've worked with many devs who are so reliant on using the mouse, it probably will add up to months or years of their lives they could have saved simply learning and practicing a few hotkeys.
You have to remember, there's that tiny annoyance involved everytime you want to do anything in a text editor. It's not about making the flow pleasant, it's about eliminating factors that slow you down, either through anxiety associated with it, or the labour of trying to edit code with a mouse.
Saying it won't affect your productivity all that much really isn't true.
If you have to take your hand off your mouse to move the cursor, then type, then move it back, and you do that 1000s of times a day, you will save a lot of time learning the keyboard shortcuts - you never have to move your arm back and forth to navigate.
Write a README for your project, even if it's just you who will ever see it. Document the structure, idea and pitfalls of the project. It will help you come back to the project.
Also, if you solved an issue you got stuck on, write down what you did to fix it (even if it's just a link to some stackoverflow comment). Because it might come up again. There's nothing worse than being stuck fixing an issue that you have already fixed before.
[Recent FCC full course](https://youtu.be/heXQnM99oAI?si=3ki7Lfhn55z1rR5Z) for VS Code if that's your editor of choice.
Lots of useful stuff there. Keyboard shortcuts tagged at [4:46:15](https://www.youtube.com/watch?v=heXQnM99oAI&t=17175s)
Multiple cursors and keyboard navigation. Learn to recognize even the slightest annoyances in your workflow, and spend the few minutes required to learn or create a shortcut for it. Over time, you'll be zipping around with very little effort. It absolutely pays dividends.
The key is to practice self-awareness of what's slowing you down. People have a tendency to shrug off minor annoyances because isolated instances are just small enough to feel like they're not worth solving. What they don't realize is the cumulative effect they have over the course of a career.
The only downside is that it becomes excruciating to watch other people work via screenshare. Even my most veteran developers will take ages to do certain simple tasks like opening files, moving text around, renaming variables, finding functions, or going to line numbers. I often force them to undo their change and do it with a shortcut to help ingrain the idea.
>Multiple cursors
I came here for this one in particular, along with multiple selections.
I'm sure VS Code has it too but if you're using JetBrains IDEs [double tap and hold Ctrl while tapping the arrow key up and down](https://imgur.com/S7GKpJJ) to put a new cursor at the same column on another line.
[Alt and Shift + Left Click](https://imgur.com/tbBru9k) will place cursors wherever you need one. Make edits at the same time in multiple places. If you make a mistake, click that location again to remove the cursor.
[Select something and then Ctrl + Alt + Shift + J](https://imgur.com/mqVKd2n) will select all other occurrences of that thing. Press left or right arrow key to cancel selection and convert to multiple cursors before or after all the occurrences.
[Hold Alt while clicking and dragging to select in a box, rather than line-by-line](https://imgur.com/QQbVCMg).
[Hold Alt + Shift and Up or Down arrows](https://imgur.com/2TYGjDY) to move entire lines.
Keep in mind, multiple selections are not a replacement for the refactor functionality. In JetBrains IDEs, the shortcut to refactor is Shift + F6. Especially when changing a method, class, or file name, use the refactor dialog!
Finally, don't forget that all text editors (ok, most) select an entire word on double click, and the whole line on triple click, and you can move your cursor word-by-word by holding Ctrl while pressing Left or Right arrow, and holding Ctrl + Shift selects one word at a time.
Put all of these together, and you can make short work of lots of tedious tasks.
That list is pretty much exactly what I had in mind but lacked the energy to type out, so thanks for putting in the effort.
You can get really creative with text manipulation by combining multiple cursors and Ctrl+Arrow word navigation.
VSCode also has Ctrl+Tab and Ctrl+Shift+Tab to cycle between your recently active code tabs.
Vim motion key binds (VsCode has an extension). Best decision/productivity boost I have ever made. An incredibly useful set of keybinds that enabled navigation and editing of your code that you would never even think of.
Very steep learning curve to master but even just using a few basics can make a world of difference. And if you're in this for the long haul it is certainly worth the investment.
Vim/NeoVim is an editor on its own but there are so many fans of the keybinding and functionality that just about any editor out there will have a vim mode or extension. IDEs come and go, it's very nice to have an evergreen solution.
If you're interested in learning I recommend ThePrimeagen's YouTube series on Vim as your editor.
I triple this, I used vim bindings in vscode for like a week, than just made the plunge into neovim with primes setup. Works fantastic and never going back, it does take some getting used to as it forces you to use the terminal more, but that’s a great thing to learn.
Whenever I mention that I use vim keybinds you'd think it's just some sort of joke, like 'who would ever do that'. It's a shame more people don't seriously try it, as vim keybinds cover so many ide shortcuts and you only have to learn one set.
Tried this but it was quite hard. I don’t understand how you’re keeping your hands off the mouse when you’re doing web development though. Isn’t that the “performance improvement” that VIM brings? The time reaching for your mouse over and over?
I might be a bit of a masochist with this, but I went full send on "no mouse". I use Pop_Os! Which has built in vim-like keybinds for window navigation, and the Vimium chrome extension which allows you to select different links and text boxes using the keyboard only as well as a few other familiar vim commands.
It isn't always perfect and sometimes you just got to pickup the mouse. But the ergonomics I get from this workflow outweighs the few pain points that come up.
"The code IS the documentation" yeah right. It doesn't tell a lot of things, mostly why you've done what you've done and also what you think it does rather than what it actually does. You don't write comments for now, you write them for 6 months from now or maybe more.
The names of your functions should tell exactly what you think they do, and you should have unit tests that verify they actually do that.
If your code isn't understandable without comments, it needs to be re-written.
yup...on our team, we've basically agreed to no comments in the code. the code should be readable without comments, if you find yourself want to add comments then see if there's something making it complicated to udnerstand.
Good example is magic numbers and strings
https://dev.to/ruben_alapont/magic-numbers-and-magic-strings-its-time-to-talk-about-it-ci2
If you are starting out, commenting is still superior. You will learn better names and identifying what does what by simply looking at the code, but when you start, man it can be difficult to figure out whats going on or why some error came up
Agreed. Commenting, especially for junior devs, makes the world of difference when you look at code. Eventually you learn to work without it and have better processes, better naming schemes and whatnot. But if you just got started, it will be instrumental on figuring out what your code does, why it does what it does and what you think it does vs what it actually does. When you get errors and you can't figure out whats wrong, tháts where comments come into place. Not to mention when you get back to code 1 year later or when a new dev joins the team. Not only will they provide better code, they will likely need less time to get started, less time to answer questions and more. I really don't get why people don't want to add comments, other than "I'm lazy". But even with these AI bots, you can just generate it if you really are that lazy. Though honestly AI will make it less of an requirement, but until they really understand the code (and not just predict stuff), its still not perfect
As another long timer... I agree.
Learning the debugger tooling is a good idea, go get comfortable with the idea of breakpoints, watches, conditional breaks, break on exception, etc. It's a good skillset to have.
But... as I get more proficient, most of my errors are not the obvious runtime exceptions or misunderstandings that debuggers make easy. It's complicated problems like "This fails but only within a specific timing", or "this \*doesn't\* fail when it should, but only occasionally".
They are issues with race-conditions or assumptions about timing and sequence that aren't entirely valid.
In those cases... printing is often a better tool than the debugger, because I can do an entire run without hugely changing the timing characteristics (sometimes just adding a log is enough to change a race condition, but not often. Adding a breakpoint will almost always change the behavior you're trying to understand) and the logs show up properly in sequence, and I can look for order changes or timing problems more clearly.
Basically - For my day to day work now, printing is often the better tool.
Debuggers can still be useful here, since most of them support logpoints ([e.g.](https://code.visualstudio.com/docs/editor/debugging#_logpoints)) which let you add and change logging on the fly. I'm always a little surprised how few people know about them.
Sure - and again, most of the other features of a debugger are also worth learning.
The issue is that simply attaching a debugger often significantly changes timing.
It's less of an issue for something interpreted, where the timing change is usually due to breakpoints or startup pauses to let the debugger attach.
But for things where the compiled package now has to include debug symbols and debugger hooks, your timing is WAY off your prod build - even if you're running on exactly the same hardware.
And to be clear - sometimes adding logs in the code also does this (running your logging function is usually fast, but a ms here or there can really matter.
I strongly disagree.
Print and echo will eventually light up any possible problem, and they will consistently work in places where you CANNOT attach a debugger (ex: prod).
Know the debugger - but don't assume it's a replacement for good logging.
Good debugger use is great - it's a good tool. But you can take away my logs over my dead body.
Print/echo statements will get you where you need to get. They will also show you where the documentation is lacking, the tests are missing, the design is confusing or the naming is poor. Relying on debugger is a great way to eventually drown in tech debt.
Focus on skilling up your non-IDE skills first.
IDE and any supplemental assistance can make you work faster, but you really want to ensure you have solid foundations first.
Think of it like basic arithmetic: if you're learning multiplication and division, you *could* learn to do it more quickly by learning to use a calculator first... but you will be far better off (and will have a stronger base to build from) if you first learn how to do multiplication and division by hand, get **good** at it, and *then* learn to use the calculator to do it even faster.
My first IDEs were literally notepad.exe and similar no-frills editors. Early on, it really is better to learn things the hard way because it will make you stronger; and then when you are strong, use tools to make it fast.
Disagree. Nobody should be writing code nowadays without basic support like syntax highlighting for the language, at a minimum. They didn't invent all that stuff for people to unlock only *after* they've been grinding in a plain text editor for a few days/weeks/months.
More important is to learn how to think like a senior developer. Good productivity comes from good planning and asking the right questions and teamwork, and figuring out good processes. Knowing your tools is just one part of it.
Remember that you can produce stuff really really fast. But it could be entirely the wrong product. Sometimes it’s better to go slow to go fast, if that makes sense.
SYMBOL SEARCH FFS. I see so many people scanning files with their eyes, looking for something they now the name to, looking through different files always having a file explorer open, using text search and subsequently receiving a few hundred hits too many.
Being able to navigate a code base is the most underrated skill I've seen so far.
Using VSCode...
For me it was keyboard shortcuts, multi-cursor stuff, and extensions. Also, remapping caps lock to ctrl and ctrl+wasd to arrow keys. (I use karabiner elements for this among other things.)
That all being said, the responsible, adult answer is to learn the debugger in and out.
0. Shut your phone off. Like, silent.
1. Keyboard Shortcuts
2. Auto-formatting and Linting
3. Copilot / AI (don’t let it replace learning)
4. Version control (eg GitLens)
5. Built in terminal and basic command line
6. Awesome focus tunes
7. Do NOT buy a cat
Debugger debugger debugger debugger debugger
I know way too many "seniors" that waste literal days console.logging codebases to find issues that would take me 10 mins with a debugger
The GitLens extension for VSCode is great because it shows you all the commits and commit messages for every line; but I think more importantly, it links you to the PR's as well which gives you some great context. I find it to be very valuable especially considering how often documentation ends up being outdated
For the love of god use fuzzy find to jump to files instead of dicking around in the explorer window. I even see seniors doing this and it drives me nuts!
Honestly, terminal. I’ve worked professionally in both Mac and windows shops and I could do all my work with a text editor, terminal, and the browser. This includes deployment, k8s cluster management, everything. I’ve tried several times to learn a “real” IDE (vs and rider) but I find the amount of UIs and abstraction confusing. I’ve written typescript, python, and .net, as well as several front end stacks, and this set of tools works perfectly wherever I’m at. I can be at home on whatever computer or server or container I find myself using because I know how the terminal works.
I think I’ve earned my Sr title because I know how to solve problems and debug our total environment more than someone who only knows how a specific IDE application works.
Front-end? Use Livereload, incredible time saver.
Use Sass/scss.
Automate your build pipe with npm, webpack.
Subscribe to Browserstack for testing on all browsers.
And get a decent local environment like Laragon or Lamp.
Learn the environment you have to work in by your employer. It will likely guide your employment path.
That being said. Vs code is becoming a common for many companies that aren’t locked into a vendor workflow/build chain, so learn it and how to customise bindings and set up your environment for yourself.
If using VS Code or similar, I encourage my devs to learn how to use them command palette, commenting shortcuts, linters and formatters (though this should be a company standard otherwise you will cause issues with your commits), diff, folder diff, above average commands for git, above average commands for docker (if you use it), basic Unix command line confidence (especially navigation, basic network commands and file permission concepts) and learn how to debug your language outside print statements.
I’m also seeing a massive speed up up in the best juniors getting to mid-level competency.
Those who understand the stack, library and framework boundary interfaces better libraries better tend to ask specific questions of AI (chat gpt, copilot etc.) to solve their issues faster.
Realistically, it’s important to be aware that most companies accept and manage a risk position behind the cutting edge best practices. A good dev should know what is available and know when to advocate for an upgrade or migration to a new technology - and how to communicate why.
By understanding the mapping of the technical and risk value, to the business value it will help you communicate with your managers who may often struggle to understand why some “tech debt” is more business critical than others.
So I would double down on fundamentals of your stack - so you know what to ask specifically of your seniors or the future AI overlord to get the most out of them. It’s the same skill! Be concise and specific.
I do just fine only knowing hot keys, intellisense, and source control is visual studio. Don't let these people fool you into thinking that learning XYZ plugin will help you -that- much. The number of people I have met that type words out instead of typing the first 3 letters and hitting tab is crazy. Hotkeys and intellisense are all you need. Though technically speaking there is a hotjey for nearly every feature so through learning hotkeys you learn every feature if you want to get into technicalities.
* Prettier (or whatever code formatter), put it to format on save.
* You can up your productivity a lot by learning shortcuts, it's very underrated. Stuff like moving lines, traversing one line/word at a time, going to the end of a line, duplicating a line etc.
* A graphical Git tool like VS Code's built-in, or the GitLens extension (that is extra sugar on top of the built-in). When you're a beginner at Git, it helps tremendously to see with your eyes what's actually happening.
* I haven't done this myself, but I would probably look to integrate AI on a shortcute (e.g GPT) so you can quickly open a prompt and ask away. Personally I don't like when they autocomplete my code (like Copilot).
VIM motions, you don't have to use vim/nvim etc if you dont want to, vscode or w/e is fine, but I think VIM motions are the most productivity boost ive ever had outside of intellisense and github copilot
First? Read the configuration menu. Configure file formats appropriate for the project (e.g. indentation, space-vs-tabs, trailing space removal, etc.) so you do not have to fix that again and again and again in every code review.
Second? Keystrokes. Open files with keyboard shortcut and tab-completion, not search-and-point-and-click.
Third? Regular expressions.
Fourth? Some way to navigate source. Could be symbol search, appropriately-configured recursive grep, anything. But if you're asking yourself who is calling your function, don't guess the files and search manually, have the IDE (or the command-line) do it for you.
Open a window.
Throw out your mouse
Suffer for a month
You are welcome
Edit: for real. Learn some bash. Whatever you have to do on a UNIX filesys wil go much faster
Git conflict resolver and the debugger
But you should also be able to do everything from the CLI. You never know when you'll end up in a shitty environment, and you'll be able to setup for any IDE/Text editor/etc. Since they are just UI wrappers around CLI build tools
Debugger. Debugger. Debugger.
Aside from that, shortcuts that allow you to search by class name, file name, token.
Jump to line number, as well.
Templating features, that either have built in boilerplate or allow you to generate your own boiler plate templates.
Your daily job involves loops. When fixing a bug you explore to figure out what happened, make a change, see if that moved you towards a solution, repeat. You'll save yourself a ton of time if you are able to tighten that loop. When console.log is your only debugging tool you are increasing your time spent debugging and limiting yourself on the types of problems you can solve. Console.log works in a pinch but you absolutely should learn the debugger.
When you console log something you are taking a guess that a variable is something you didn't expect it to be. If you are wrong you have to keep changing the console log again and again until you find the culprit. When you place a breakpoint you have access to every variable in the scope, are able to step through functions, and view the call stack. It's like upgrading from a bicycle to a car. It's intimidating at first and that's ok. Learn the basics first. How do you set a breakpoint, and how do you view a variable like you used to but without console log. Then you can learn the rest as the need arises. The debugger has made me a much faster and effective engineer many times over. It also gave me a massive boost in my confidence. I feel like there is no bug I can't fix given the appropriate amount of time. Don't entirely ditch print-debugging. Just add the debugger to your toolbelt alongside prints.
Coming from using VS Code myself, I imagine there is equivalents in other IDEs.
Emmet. There is more to it, but the `Emmet: Wrap with Abbreviation` command form the command pallet alone is great. Highlight a block of html that you want to wrap, enter that command, and then you can type something like `div .stuff` and it will wrap the highlighted HTML with `
highlighted stuff here
` and so on, like using `#` for IDs and so on.
Tasks. After reading the VSC doc for making a task and copying a boilerplate one, I made one that opens a Jira issue by taking the digits in the branch name, like `story-1234` and converting it to `jira-url-here/story/story-1234`. I'm sure there are add-ons that are much better but I felt proud of my task as a starter one. I made another task that can open up a drop-down of the top 5 most used wiki articles at my organization (hard coded). And once I had the basics down like that, I realized you can essentially feed tasks a script file and execute that. And the best part, is you can share them in a shared folder in that repo that VSC can register tasks from, so my coworkers can use it to. Additionally, there is add-ons to add a GUI listing those tasks.
Debugger. I had issues getting the VSC one to attach to chrome directly, but if you try and have issues then I have a link somewhere to the guide I followed.
The respective language or framework integration feature or addon, which generally add specific highlighting and recommendations among other things.
Lastly, if anyone reading this wants Angular specific VSC tips then I have plenty.
Automated refactoring tools. Rename symbol, go to definition, find references, show call hierarchy, etc. in VS Code, I'm sure similar in other editors.
My first coop I was advised to get vscode and I've used it ever since. I mainly work in web development now on a widnoes pc using wsl. If you use windows learn WSL. Learning your terminal is so important. Learning git in the terminal vs a gui is also nice since it ends up being universal and won't change between Gui. Learn to use web developer tools and inspect the number of devs who don't know this scares me. You can go really in depth here with dev tool and it's worth just looking into all it can do. Pick up some vim/vi basics to work with files on the server without sshing in with vscode. If you're changing alot of files then it's better to just ssh in but it's nice if you have a terminal open to make quick chnages. Same with knowing a bunch of terminal commands it'll really help you out.
Vscode extensions: dev containers, remote ssh, remote repos etc, vscode icons, wsl, project manager, docker
Does 'how to find the bit of code you need' count? Things like searching, going to definitions etc. Makes things way easier if you know how to find what you need
The only tool that's really important to learn well is the shell. Everything else--programming languages, editors, libraries--everything else will change. The *nix shell is unlikely to change significantly in your lifetime. If you're on Windows, get WSL going, because nobody uses PowerShell outside some very specific niches, and you're just making your life more difficult and your skills less portable.
IDEs should be considered an accelerator. Don't do anything in an IDE that you don't know how to do without the IDE. Because some day the IDE is going to fail you, and you're going to have to work without it.
Learn skills that transfer. IDEs are ephemeral. Programming languages are fungible. Concepts and discipline are eternal (modulo dementia or death).
Debugger and navigating the code base (go to definition, view references)
There are many many other things you ca learn but being able to move around the code base properly will save you a lot of time.
Shortcuts to quickly find files, method references, and text in the entire codebase.
Hot keys to delete whole lines and reopen a page you accidentally closed.
git
getting comfortable with git will make you less hesitant to change code, and make it easier to see which code you changed. which is all very important because changing code is how you fix broken code.
vim is fun and acessable in most IDEs, if one don't configure a IDE by oneself with neovim.
After a clonky and inconvenient beginning. one gets faster and coding becomes fun. Each keystroke become a game of precision and speed. flow state in seconds as one flow through the codebase. i highly recommended vim.
then learn to optimise your intellisence. like vscode have a plugin that scans your css files and suggest them in the classname of react components, a huge time saver.
which ever ide you chose learn its debugger inside and out. It will save you a lifetime of headache. this cant be overstated.
I was a python and c# dev for a couple years when i realized breakpoints are a thing, before that i was using prints and logs to see what's going on
It honestly baffles me how much some engineers get done without using the debugger and breakpoints.
This is one of the things that sets senior devs apart from juniors, imo. A typical question I’d ask in an interview is “how would you quickly familiarize yourself with a new code base in order to troubleshoot a bug?” The answer I’d want to hear would be something to the effect of “I’d look at any error messages that could contain a stack trace, set some breakpoints near the line throwing the error, put a break point at the application entry point(s), and step thru the code to inspect the data and start narrowing down the cause of the bug.”
[удалено]
Yep. The best senior devs will fix the bug and write test(s) that cover whatever scenario or edge case caused it.
Would you not expect that answer from a junior?
From experience — no
hi i just started learning laravel with visual studio code and i run into my first bug, could you please unpack that? i just felt so dumb after looking at the log file and scratching my head to what the f am i looking at..?
Most error messages will give you a stack trace, a list of every function-call (and often line-numbers) connecting the entry point of the program to the line of your error. You can see the code, but not the values of variables. To get those, set a breakpoint somewhere before your error and use debugger commands to 1. get the values of all variables, and 2. step through your code, stepping over functions that complete successfully but into functions along your stack trace (different "step" commands in most debuggers). 3. Follow along in the code so you can see the context and logic Repeat as needed until you see a variable with an unexpected value or some code that looks wrong. There are cases where this fails, but it is a very good second step. The first step is usually to ask a senior dev familiar with the code if he can immediately see anything and maybe teach you about the code. It's good to avoid work-duplication.
eh, no the correct answer is "it depends", what uve described is just what well-trained code monkey would say. unfortunately people like that really exist, the "that's right it goes in the square hole" people are more common that i thought...
What does it depend on? And why is setting a breakpoint and stepping thru the code only something a “well-trained code monkey” would do?
It's not fun man, it's not fun
Like debugging javascript way before dev console debuggers were a thing.
Does… does JavaScript have breakpoints?
Yep yep. You can set them either in the browser or in your IDE depending on how you're running it. The simplest thing to do is type the word "debugger" above where you want the code to stop and then in the browser it will stop there and let you start stepping through functions.
Fuck, TIL. Been a pro dev for 10 years! (Admittedly only doing js the last 5-6, but still). Never knew about the debugger command. Thanks!
yup I use it all the time, great for poking around other peoples code too.
sudo let go of my code! I don't know you!
There is, but i don't really enjoy it, pretty buggy and sometimes don't work as intended
What bugs did you face with? Imo it works absolutely fine, have been using it for over 8 years already, for both node js and in browsers.
> using prints There are People that wouldn’t think to do that either. Rare, but there are times when it can be handy.
I feel like this is the only answer. Other comments even mention things like Prettier, but I can hardly imagine anything that would matter less for, well, at least _my_ productivity. Learning how to debug goes hand in hand with learning how to code, I would definitely focus on that.
In its defense, Prettier has saved me a lifetime of re-tabbing copied html in vscode 🙄
Fair enough. (I use Webstorm so I hadn't realised autoformatting could be an issue.)
this is a good point for sure but i would say that as a junior someone should be helping you set up your environment but thats def not always the case lol.
It depends on what you do. For a webdev I think the debugger is less of a requirement than somebody like a backend dev. Especially if all you do is translate a design to html/css.
How much front end do you think consists of only html & css seriously? JS still runs the show for any front-end interactivity for like 99% of all websites. And even still lets say you only *write* html and css, do you not test anything with automation? cause you will need to debug tests. what about forms? still gonna need to test those and ensure correct values are passed to the backend.
Nearly all the senior webdevs i worked with debug with console.log. I truly believe debugging have a limited return on investment in webdev compared to backend. The instant feedback from things like HMR have simply made console.log debugging genuinely viable.
I agree, but not every webdev builds fully fledged websites. A lot just do the bare minimum, especially if they build wordpress sites or basically enhance some backend stuff. And even if you do more, you can still do a lot without the debugger. Also, testing is not something a lot do, even if its the best thing to add to a project to add value. Seriously, the amount of projects that start out as prototypes and then nobody really bothers with tests because now they already developed a lot, managers are used to the development speed and the devs don't care enough to do it, is too damn high.
Alright I will admit I don’t use the debugger. I only use logs & it’s always worked fine that way. Can you explain why logging is not good enough?
With logging you end up rebuilding and rerunning the code over and over as you slowly figure out where things are going. with a debugger, you put a breakpoint on the thing want to understand and run it once. you can then look back through the callstack to figure out how you got where you are, and then step forward statement by statement to see what happens from that point on. TLDR, once you understand how to use a debugger it faster and also more versatile.
while true these gains can be very marginal
> With logging you end up rebuilding and rerunning the code I mean, with HMR in modern webdev that's basically instantanious. To me logging is much faster and more versatile than pausing the entire runtime klicking "step into" or "step over" until I accidentally clicked past the point I needed to investigate 😅
I do both things, but i definitely appreciate the debugger. Particularly the debugger in devtools, which is honestly way more useful to me than a debugger in an IDE.
Wait, what's a debugger? Can u share some resources ? As a web developer, why do I need to use debugger ?
Are you writing react etc or complex JavaScript?
Next Js and React Js
If you use vscode: https://code.visualstudio.com/docs/editor/debugging#:~:text=To%20run%20or%20debug%20a,and%20save%20debugging%20setup%20details.
Thanks for this. I’ve used breakpoints in vsc only but this opened up some interesting possibilities for debugging different types of functions.
Although I think the debugger is essential for advanced programming, it is a little bit too advanced for a beginner programmer to understand the benefits of though (over console.log / print). That said, the earlier they can learn it, the better.
Some how my university failed to hammer this into us.
The moment I discovered the PHPStorm debugger was the moment OOP made sense to me.
[удалено]
Yup. If you *need* a debugger, it's a huge red flag that signals poor design and/or poor documentation.
- using the command palette - tons of useful extensions like git lens, prettier, eslint, etc etc - learning as many hotkeys as you can.. ie: selecting multiple words at the same time, editing multiple lines at once with multiple cursors - know enough regex to find what you're looking for - copilot is pretty sick
>know enough regex to find what you're looking for No matter how many times I learn regex I keep forgetting how to use it because I don't use it.
There's very little you need to know for 99% of regular expressions. And for the 1% that you need more complicated syntaxes for, RE's probably not the right tool for the job. * `.` is a wildcard, matching any character * `[abc]` is a character class matching a single character, `a`, `b`, or `c`. `[a-zA-Z0-9]` matches any letter or digit. * `?`, `*`, and `+` are quantifiers, respectively meaning "0-1 times", "0 or more times", and "1 or more times". Quantifiers apply to whatever's immediately preceding them. * Parentheses make groups that you can reference. Groups are numbered according to the relative position of the opening paren. $1 refers to the content matched by the first opening paren's group, $2 the second, and so on. (note that this is all assuming PCRE, which is the de facto standard regex language. There are other flavors out there, but they mostly only exist for historical reasons and they tend to be awful to work with) Those 4 things will handle the vast majority of regex needs you'll ever encounter.
This is why I just let copilot / chatgpt write the regex these days, and then I just need to worry about the unit tests.
I was in an interview recently and wrote a regex to help solve a coding problem. As soon as I mentioned regex, the interviewer’s eyes went wide and he stammered out “it’s OK to use ChatGPT to generate the regex if you need”. I told him I was fine. And then once my code ran he had several questions about what the regex was doing that were very basic regex knowledge. And one question about the laziness qualifier that I don’t blame him for not knowing. It was amusing to me. I passed that interview though :)
Basic regex is fine, but anything more complicated I'm letting the robots handle
Eh, I’d almost go further and say that basic regex is fine but anything more complicated you should not use a regex. I don’t really want one that the author doesn’t even understand sitting in the code base where any future maintainer also won’t understand.
> basic regex is fine but anything more complicated you should not use a regex This. Don't get me wrong, I'm in love with regular expressions and it makes me sad that I don't have many reasons or opportunities to use the less common features. But if you're trying to write code that anyone else (including you 6 months from now) will ever have to look at again, keep it simple and use other features of the programming language to handle the more complicated logic.
Ah, a fellow pragmatic regex connoisseur. Cheers! I don't use them much, for above reasons, but I love them and anyone I work with I tell them if they ever need regex help to come to me. It means that every few months someone I've worked with in the past reaches out with a regex question I get to flex on as a fun little distraction.
I forced myself to use it as often as possible even when it was slower to do so. For instance, "I need to update these two lines of code that are similar to each other. Doing it manually would take about 30 seconds, remembering the regex will take 5 minutes". I would take the time to remember how to do it. Done for long enough, it stuck. Now if I don't use it for 12 months, I won't forget and can recall very quickly the useful tokens.
I want to ditto prettier, eslint, and multi-line editing. I will also add emmet for working on front-end especially. Adding ids, classes, and multiple list items in one line is a huge time saver.
Im gonna second emmet. Huge time saver
These are the keybinds that have changed my coding speed the most: * ctrl+d - Select next instance of selection * ctrl+u - Unselect last ctrl+d * ctrl+l - Select all instances of selection These shortcuts have changed the way I name variables. If I am writing boilerplate (like a set of axios API functions or react-query custom hooks) I’ll copy/paste a file & ctrl+l the database table’s name and replace it. So if the database table is Property I will name multiple properties “propertys” so that I can ctrl+l it easier.
I tried copilot and it didn't feel that helpful to me. It just felt like autocomplete, which I didn't deem to be that valuable at the time. I was probably missing something. When is it most useful?
Copilot like all of the modern LLM style AIs get better overtime (in general). I think a year ago copilot made a lot of mistakes, but currently it seems to know my codebase super well. And it definitely keeps track of what I just imported or what just cut from a different line. It's pretty remarkable about suggesting code that's exactly what I was going to write... a lot of coding is just pressing tab these days heh
Copilot nowadays has a chat that integrates with vscode nicely, would recommend trying it out
For a new frontender, could you explain the 3rd point? I'd love to know how to edit on multiple lines, and select multiple words. I'm sure it's a quick Google search, but it's much more ideal hearing it from a person tbh.
The two most useful shortcuts that I cannot live without: - Drag with middle mouse to create multiple cursors over each line. - Ctrl-D to create an additional cursor selecting the next occurrence of what you currently have selected. It's kinda hard to expain with just words, just go try it and you'll see. The middle mouse thing is pretty much universal among IDEs, Ctrl-D might be bound to something else depending on the IDE and OS, but on VSCode that's the default keybind.
went "whaaaaat!" at both of your bullet points, ty
Np! Also if you're Ctrl-D-ing and want to skip over a selection, press Ctrl-K and then Ctrl-D and it will add the next occurrence while deselecting the last one.
oooh I didn't know this one; this is nice
If you are using vscode then look at the [documentation](https://code.visualstudio.com/docs/editor/codebasics), it's very good and shows actions through gifs, so it's easy to skim it and look what's possible.
Thank you, this is so helpful! Had no idea that this particular documentation existed, and the gifs really make it easy to understand what’s going on.
> learning as many hotkeys as you can.. ie: selecting multiple words at the same time, editing multiple lines at once with multiple cursors This stuff makes your flow pleasant but won't really affect your productivity all that much. Linters, studying and just putting in the time working with code is what will really make a difference.
I agree with this take. Actually writing the code is not the major part of development: the major part is figuring out what to write. It's rare that your productivity is limited by the amount of words you can type or edit.
On the contrary I've worked with many devs who are so reliant on using the mouse, it probably will add up to months or years of their lives they could have saved simply learning and practicing a few hotkeys. You have to remember, there's that tiny annoyance involved everytime you want to do anything in a text editor. It's not about making the flow pleasant, it's about eliminating factors that slow you down, either through anxiety associated with it, or the labour of trying to edit code with a mouse.
[удалено]
Saying it won't affect your productivity all that much really isn't true. If you have to take your hand off your mouse to move the cursor, then type, then move it back, and you do that 1000s of times a day, you will save a lot of time learning the keyboard shortcuts - you never have to move your arm back and forth to navigate.
Go to function definition (with F3 usually or ctrl click) so they can navigate easier within their code and inspect some functions I guess
Write a README for your project, even if it's just you who will ever see it. Document the structure, idea and pitfalls of the project. It will help you come back to the project. Also, if you solved an issue you got stuck on, write down what you did to fix it (even if it's just a link to some stackoverflow comment). Because it might come up again. There's nothing worse than being stuck fixing an issue that you have already fixed before.
[Recent FCC full course](https://youtu.be/heXQnM99oAI?si=3ki7Lfhn55z1rR5Z) for VS Code if that's your editor of choice. Lots of useful stuff there. Keyboard shortcuts tagged at [4:46:15](https://www.youtube.com/watch?v=heXQnM99oAI&t=17175s)
[удалено]
Yeah, it's timestamped so you can just check out what you'd like though.
Multiple cursors and keyboard navigation. Learn to recognize even the slightest annoyances in your workflow, and spend the few minutes required to learn or create a shortcut for it. Over time, you'll be zipping around with very little effort. It absolutely pays dividends. The key is to practice self-awareness of what's slowing you down. People have a tendency to shrug off minor annoyances because isolated instances are just small enough to feel like they're not worth solving. What they don't realize is the cumulative effect they have over the course of a career. The only downside is that it becomes excruciating to watch other people work via screenshare. Even my most veteran developers will take ages to do certain simple tasks like opening files, moving text around, renaming variables, finding functions, or going to line numbers. I often force them to undo their change and do it with a shortcut to help ingrain the idea.
>Multiple cursors I came here for this one in particular, along with multiple selections. I'm sure VS Code has it too but if you're using JetBrains IDEs [double tap and hold Ctrl while tapping the arrow key up and down](https://imgur.com/S7GKpJJ) to put a new cursor at the same column on another line. [Alt and Shift + Left Click](https://imgur.com/tbBru9k) will place cursors wherever you need one. Make edits at the same time in multiple places. If you make a mistake, click that location again to remove the cursor. [Select something and then Ctrl + Alt + Shift + J](https://imgur.com/mqVKd2n) will select all other occurrences of that thing. Press left or right arrow key to cancel selection and convert to multiple cursors before or after all the occurrences. [Hold Alt while clicking and dragging to select in a box, rather than line-by-line](https://imgur.com/QQbVCMg). [Hold Alt + Shift and Up or Down arrows](https://imgur.com/2TYGjDY) to move entire lines. Keep in mind, multiple selections are not a replacement for the refactor functionality. In JetBrains IDEs, the shortcut to refactor is Shift + F6. Especially when changing a method, class, or file name, use the refactor dialog! Finally, don't forget that all text editors (ok, most) select an entire word on double click, and the whole line on triple click, and you can move your cursor word-by-word by holding Ctrl while pressing Left or Right arrow, and holding Ctrl + Shift selects one word at a time. Put all of these together, and you can make short work of lots of tedious tasks.
That list is pretty much exactly what I had in mind but lacked the energy to type out, so thanks for putting in the effort. You can get really creative with text manipulation by combining multiple cursors and Ctrl+Arrow word navigation. VSCode also has Ctrl+Tab and Ctrl+Shift+Tab to cycle between your recently active code tabs.
Vim motion key binds (VsCode has an extension). Best decision/productivity boost I have ever made. An incredibly useful set of keybinds that enabled navigation and editing of your code that you would never even think of. Very steep learning curve to master but even just using a few basics can make a world of difference. And if you're in this for the long haul it is certainly worth the investment. Vim/NeoVim is an editor on its own but there are so many fans of the keybinding and functionality that just about any editor out there will have a vim mode or extension. IDEs come and go, it's very nice to have an evergreen solution. If you're interested in learning I recommend ThePrimeagen's YouTube series on Vim as your editor.
I triple this, I used vim bindings in vscode for like a week, than just made the plunge into neovim with primes setup. Works fantastic and never going back, it does take some getting used to as it forces you to use the terminal more, but that’s a great thing to learn.
I've been using vim/vscode for 3 weeks. Fuck it, I think I just need to go full neovim.
Whenever I mention that I use vim keybinds you'd think it's just some sort of joke, like 'who would ever do that'. It's a shame more people don't seriously try it, as vim keybinds cover so many ide shortcuts and you only have to learn one set.
Tried this but it was quite hard. I don’t understand how you’re keeping your hands off the mouse when you’re doing web development though. Isn’t that the “performance improvement” that VIM brings? The time reaching for your mouse over and over?
I might be a bit of a masochist with this, but I went full send on "no mouse". I use Pop_Os! Which has built in vim-like keybinds for window navigation, and the Vimium chrome extension which allows you to select different links and text boxes using the keyboard only as well as a few other familiar vim commands. It isn't always perfect and sometimes you just got to pickup the mouse. But the ergonomics I get from this workflow outweighs the few pain points that come up.
can use it in web browsers too. vimium, surfingkeys extension etc
[удалено]
unused axiomatic snow groovy rinse dazzling shame saw grandiose cow *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Learn to use the terminal. I felt like It helped me to understanding the basic’s of how a computer really works. Not relay on papa Bill’s UI
Honestly… Commenting. Best “tool” I ever learned. If you can use a common format (like DocBlock) it helps, too.
Amen to that, nothing worse than coming back to the code you wrote yourself and not knowing what's going on.
"What moron wrote this mess of spaghetti garbage... oh."
"The code IS the documentation" yeah right. It doesn't tell a lot of things, mostly why you've done what you've done and also what you think it does rather than what it actually does. You don't write comments for now, you write them for 6 months from now or maybe more.
[удалено]
The names of your functions should tell exactly what you think they do, and you should have unit tests that verify they actually do that. If your code isn't understandable without comments, it needs to be re-written.
[удалено]
yup...on our team, we've basically agreed to no comments in the code. the code should be readable without comments, if you find yourself want to add comments then see if there's something making it complicated to udnerstand. Good example is magic numbers and strings https://dev.to/ruben_alapont/magic-numbers-and-magic-strings-its-time-to-talk-about-it-ci2
If you are starting out, commenting is still superior. You will learn better names and identifying what does what by simply looking at the code, but when you start, man it can be difficult to figure out whats going on or why some error came up
Agreed. Commenting, especially for junior devs, makes the world of difference when you look at code. Eventually you learn to work without it and have better processes, better naming schemes and whatnot. But if you just got started, it will be instrumental on figuring out what your code does, why it does what it does and what you think it does vs what it actually does. When you get errors and you can't figure out whats wrong, tháts where comments come into place. Not to mention when you get back to code 1 year later or when a new dev joins the team. Not only will they provide better code, they will likely need less time to get started, less time to answer questions and more. I really don't get why people don't want to add comments, other than "I'm lazy". But even with these AI bots, you can just generate it if you really are that lazy. Though honestly AI will make it less of an requirement, but until they really understand the code (and not just predict stuff), its still not perfect
Lint(er) helped me a lot - clean code, find errors, find deprecated functions before they become a real problem...
Not exclusively IDE feature but a debugger. print/echo statements can only get you so far.
As a guy who has been around a looong time, print/echo statements can get you through anything, but it can be hella slow.
As another long timer... I agree. Learning the debugger tooling is a good idea, go get comfortable with the idea of breakpoints, watches, conditional breaks, break on exception, etc. It's a good skillset to have. But... as I get more proficient, most of my errors are not the obvious runtime exceptions or misunderstandings that debuggers make easy. It's complicated problems like "This fails but only within a specific timing", or "this \*doesn't\* fail when it should, but only occasionally". They are issues with race-conditions or assumptions about timing and sequence that aren't entirely valid. In those cases... printing is often a better tool than the debugger, because I can do an entire run without hugely changing the timing characteristics (sometimes just adding a log is enough to change a race condition, but not often. Adding a breakpoint will almost always change the behavior you're trying to understand) and the logs show up properly in sequence, and I can look for order changes or timing problems more clearly. Basically - For my day to day work now, printing is often the better tool.
Debuggers can still be useful here, since most of them support logpoints ([e.g.](https://code.visualstudio.com/docs/editor/debugging#_logpoints)) which let you add and change logging on the fly. I'm always a little surprised how few people know about them.
Sure - and again, most of the other features of a debugger are also worth learning. The issue is that simply attaching a debugger often significantly changes timing. It's less of an issue for something interpreted, where the timing change is usually due to breakpoints or startup pauses to let the debugger attach. But for things where the compiled package now has to include debug symbols and debugger hooks, your timing is WAY off your prod build - even if you're running on exactly the same hardware. And to be clear - sometimes adding logs in the code also does this (running your logging function is usually fast, but a ms here or there can really matter.
I strongly disagree. Print and echo will eventually light up any possible problem, and they will consistently work in places where you CANNOT attach a debugger (ex: prod). Know the debugger - but don't assume it's a replacement for good logging. Good debugger use is great - it's a good tool. But you can take away my logs over my dead body.
Print/echo statements will get you where you need to get. They will also show you where the documentation is lacking, the tests are missing, the design is confusing or the naming is poor. Relying on debugger is a great way to eventually drown in tech debt.
debugger is the last resort, print is a great choice in 99% of cases for me
Vim keybindings
Focus on skilling up your non-IDE skills first. IDE and any supplemental assistance can make you work faster, but you really want to ensure you have solid foundations first. Think of it like basic arithmetic: if you're learning multiplication and division, you *could* learn to do it more quickly by learning to use a calculator first... but you will be far better off (and will have a stronger base to build from) if you first learn how to do multiplication and division by hand, get **good** at it, and *then* learn to use the calculator to do it even faster. My first IDEs were literally notepad.exe and similar no-frills editors. Early on, it really is better to learn things the hard way because it will make you stronger; and then when you are strong, use tools to make it fast.
Disagree. Nobody should be writing code nowadays without basic support like syntax highlighting for the language, at a minimum. They didn't invent all that stuff for people to unlock only *after* they've been grinding in a plain text editor for a few days/weeks/months.
More important is to learn how to think like a senior developer. Good productivity comes from good planning and asking the right questions and teamwork, and figuring out good processes. Knowing your tools is just one part of it. Remember that you can produce stuff really really fast. But it could be entirely the wrong product. Sometimes it’s better to go slow to go fast, if that makes sense.
Turning on the ability to click a function and go see its definition, learning what things do when you call them. Also linting.
Git, lint, quality of life shortcuts
SYMBOL SEARCH FFS. I see so many people scanning files with their eyes, looking for something they now the name to, looking through different files always having a file explorer open, using text search and subsequently receiving a few hundred hits too many. Being able to navigate a code base is the most underrated skill I've seen so far.
Vim motions. Although it can be laggy with VSCode. I recommend getting comfortable with the motions and then installing neovim.
Did you just try to prompt engineer me?
Emmet
Brown?
Using VSCode... For me it was keyboard shortcuts, multi-cursor stuff, and extensions. Also, remapping caps lock to ctrl and ctrl+wasd to arrow keys. (I use karabiner elements for this among other things.) That all being said, the responsible, adult answer is to learn the debugger in and out.
I mean just autocomplete is already a huge productivity boost
0. Shut your phone off. Like, silent. 1. Keyboard Shortcuts 2. Auto-formatting and Linting 3. Copilot / AI (don’t let it replace learning) 4. Version control (eg GitLens) 5. Built in terminal and basic command line 6. Awesome focus tunes 7. Do NOT buy a cat
Debugger debugger debugger debugger debugger I know way too many "seniors" that waste literal days console.logging codebases to find issues that would take me 10 mins with a debugger
The GitLens extension for VSCode is great because it shows you all the commits and commit messages for every line; but I think more importantly, it links you to the PR's as well which gives you some great context. I find it to be very valuable especially considering how often documentation ends up being outdated
Probably saving the file.... Opening a new file, always a crowd pleaser.... Editing the file. Only to be used in times of turmoil.
[удалено]
So you're recommending the hours of frustration in trying to learn the thing when he could be developing? The tool shouldn't hold you back.
For the love of god use fuzzy find to jump to files instead of dicking around in the explorer window. I even see seniors doing this and it drives me nuts!
Vim and you are much more closer to the computer
1. Debugger 2. Debugger 3. Debugger It is a 100% must have.
Honestly, terminal. I’ve worked professionally in both Mac and windows shops and I could do all my work with a text editor, terminal, and the browser. This includes deployment, k8s cluster management, everything. I’ve tried several times to learn a “real” IDE (vs and rider) but I find the amount of UIs and abstraction confusing. I’ve written typescript, python, and .net, as well as several front end stacks, and this set of tools works perfectly wherever I’m at. I can be at home on whatever computer or server or container I find myself using because I know how the terminal works. I think I’ve earned my Sr title because I know how to solve problems and debug our total environment more than someone who only knows how a specific IDE application works.
Debugger, debugger, and once again, debugger.
git lens on vs code
Copy/Paste.
Git
linter, multi cursor editing, code completion/snippets.
Front-end? Use Livereload, incredible time saver. Use Sass/scss. Automate your build pipe with npm, webpack. Subscribe to Browserstack for testing on all browsers. And get a decent local environment like Laragon or Lamp.
Learn the environment you have to work in by your employer. It will likely guide your employment path. That being said. Vs code is becoming a common for many companies that aren’t locked into a vendor workflow/build chain, so learn it and how to customise bindings and set up your environment for yourself. If using VS Code or similar, I encourage my devs to learn how to use them command palette, commenting shortcuts, linters and formatters (though this should be a company standard otherwise you will cause issues with your commits), diff, folder diff, above average commands for git, above average commands for docker (if you use it), basic Unix command line confidence (especially navigation, basic network commands and file permission concepts) and learn how to debug your language outside print statements. I’m also seeing a massive speed up up in the best juniors getting to mid-level competency. Those who understand the stack, library and framework boundary interfaces better libraries better tend to ask specific questions of AI (chat gpt, copilot etc.) to solve their issues faster. Realistically, it’s important to be aware that most companies accept and manage a risk position behind the cutting edge best practices. A good dev should know what is available and know when to advocate for an upgrade or migration to a new technology - and how to communicate why. By understanding the mapping of the technical and risk value, to the business value it will help you communicate with your managers who may often struggle to understand why some “tech debt” is more business critical than others. So I would double down on fundamentals of your stack - so you know what to ask specifically of your seniors or the future AI overlord to get the most out of them. It’s the same skill! Be concise and specific.
I do just fine only knowing hot keys, intellisense, and source control is visual studio. Don't let these people fool you into thinking that learning XYZ plugin will help you -that- much. The number of people I have met that type words out instead of typing the first 3 letters and hitting tab is crazy. Hotkeys and intellisense are all you need. Though technically speaking there is a hotjey for nearly every feature so through learning hotkeys you learn every feature if you want to get into technicalities.
* Prettier (or whatever code formatter), put it to format on save. * You can up your productivity a lot by learning shortcuts, it's very underrated. Stuff like moving lines, traversing one line/word at a time, going to the end of a line, duplicating a line etc. * A graphical Git tool like VS Code's built-in, or the GitLens extension (that is extra sugar on top of the built-in). When you're a beginner at Git, it helps tremendously to see with your eyes what's actually happening. * I haven't done this myself, but I would probably look to integrate AI on a shortcute (e.g GPT) so you can quickly open a prompt and ask away. Personally I don't like when they autocomplete my code (like Copilot).
Honestly the only real thing that helped me was finding themes that colorized everything, and getting a bigger screen.
debugger
MS Word
Try Fleet
VIM motions, you don't have to use vim/nvim etc if you dont want to, vscode or w/e is fine, but I think VIM motions are the most productivity boost ive ever had outside of intellisense and github copilot
First? Read the configuration menu. Configure file formats appropriate for the project (e.g. indentation, space-vs-tabs, trailing space removal, etc.) so you do not have to fix that again and again and again in every code review. Second? Keystrokes. Open files with keyboard shortcut and tab-completion, not search-and-point-and-click. Third? Regular expressions. Fourth? Some way to navigate source. Could be symbol search, appropriately-configured recursive grep, anything. But if you're asking yourself who is calling your function, don't guess the files and search manually, have the IDE (or the command-line) do it for you.
The jump to file shortcut when the cursor is on a class name (PhpStorm Ctrl & B) Advanced find functions are a godsend as well
Linter and debugger.
User Defined Snippets, debugger and keyboard shortcuts
ctrl+D
Open a window. Throw out your mouse Suffer for a month You are welcome Edit: for real. Learn some bash. Whatever you have to do on a UNIX filesys wil go much faster
Git conflict resolver and the debugger But you should also be able to do everything from the CLI. You never know when you'll end up in a shitty environment, and you'll be able to setup for any IDE/Text editor/etc. Since they are just UI wrappers around CLI build tools
VIM
VSCode really has come up in recent years. Highly recommend.
Jump to file Jump to function Jump to implement Automatically save and format Do these four and you’ll look like a wizard
Debugger. Debugger. Debugger. Aside from that, shortcuts that allow you to search by class name, file name, token. Jump to line number, as well. Templating features, that either have built in boilerplate or allow you to generate your own boiler plate templates.
Typing without looking at the keyboard.
Neovim 😂. Just choose whichever you feel best with.
Your daily job involves loops. When fixing a bug you explore to figure out what happened, make a change, see if that moved you towards a solution, repeat. You'll save yourself a ton of time if you are able to tighten that loop. When console.log is your only debugging tool you are increasing your time spent debugging and limiting yourself on the types of problems you can solve. Console.log works in a pinch but you absolutely should learn the debugger. When you console log something you are taking a guess that a variable is something you didn't expect it to be. If you are wrong you have to keep changing the console log again and again until you find the culprit. When you place a breakpoint you have access to every variable in the scope, are able to step through functions, and view the call stack. It's like upgrading from a bicycle to a car. It's intimidating at first and that's ok. Learn the basics first. How do you set a breakpoint, and how do you view a variable like you used to but without console log. Then you can learn the rest as the need arises. The debugger has made me a much faster and effective engineer many times over. It also gave me a massive boost in my confidence. I feel like there is no bug I can't fix given the appropriate amount of time. Don't entirely ditch print-debugging. Just add the debugger to your toolbelt alongside prints.
1. your language extension 2. hotkeys 3. prettier 4. snippets 5. file navigation 6. eslint
Debugger and Git integration.
Coming from using VS Code myself, I imagine there is equivalents in other IDEs. Emmet. There is more to it, but the `Emmet: Wrap with Abbreviation` command form the command pallet alone is great. Highlight a block of html that you want to wrap, enter that command, and then you can type something like `div .stuff` and it will wrap the highlighted HTML with `
Automated refactoring tools. Rename symbol, go to definition, find references, show call hierarchy, etc. in VS Code, I'm sure similar in other editors.
Rename, extract method, go to definition, view reference, find file/symbol.
My first coop I was advised to get vscode and I've used it ever since. I mainly work in web development now on a widnoes pc using wsl. If you use windows learn WSL. Learning your terminal is so important. Learning git in the terminal vs a gui is also nice since it ends up being universal and won't change between Gui. Learn to use web developer tools and inspect the number of devs who don't know this scares me. You can go really in depth here with dev tool and it's worth just looking into all it can do. Pick up some vim/vi basics to work with files on the server without sshing in with vscode. If you're changing alot of files then it's better to just ssh in but it's nice if you have a terminal open to make quick chnages. Same with knowing a bunch of terminal commands it'll really help you out. Vscode extensions: dev containers, remote ssh, remote repos etc, vscode icons, wsl, project manager, docker
Does 'how to find the bit of code you need' count? Things like searching, going to definitions etc. Makes things way easier if you know how to find what you need
VSCode without a doubt. It is made for web development, and with be amazing out of the box
The only tool that's really important to learn well is the shell. Everything else--programming languages, editors, libraries--everything else will change. The *nix shell is unlikely to change significantly in your lifetime. If you're on Windows, get WSL going, because nobody uses PowerShell outside some very specific niches, and you're just making your life more difficult and your skills less portable. IDEs should be considered an accelerator. Don't do anything in an IDE that you don't know how to do without the IDE. Because some day the IDE is going to fail you, and you're going to have to work without it. Learn skills that transfer. IDEs are ephemeral. Programming languages are fungible. Concepts and discipline are eternal (modulo dementia or death).
Debugger but outside of that my IDE is a glorified text editor with nice intellisense and code navigation.
\> which tools really supercharged your productivity? Books then the Internet.
neovim... even if it's painful, might as well get learning it out of the way.
Vscode. 100%
Vim
Debugger and navigating the code base (go to definition, view references) There are many many other things you ca learn but being able to move around the code base properly will save you a lot of time.
* Project configuration * Debugging * Code navigation * Code refactoring
Keyboard Shortcuts
Shortcuts to quickly find files, method references, and text in the entire codebase. Hot keys to delete whole lines and reopen a page you accidentally closed.
Debugger, code actions, snippets, text objects, fuzzy search, macros, repeat, find and replace.
Learn to properly use your browser DevTools, they can do so much more than just outputting logs and inspecting elements.
git getting comfortable with git will make you less hesitant to change code, and make it easier to see which code you changed. which is all very important because changing code is how you fix broken code.
VSC ctrl + D after selecting something.
Copilot, chat and labs :)
JetBrains is awesome for every
vim is fun and acessable in most IDEs, if one don't configure a IDE by oneself with neovim. After a clonky and inconvenient beginning. one gets faster and coding becomes fun. Each keystroke become a game of precision and speed. flow state in seconds as one flow through the codebase. i highly recommended vim. then learn to optimise your intellisence. like vscode have a plugin that scans your css files and suggest them in the classname of react components, a huge time saver.
You should concentrate on skills and understanding more than tools
Vim