Welcome to #DevDiscuss
Tonight's topic is debugging!
Questions to start us off:
- How do you debug effectively?
- What lessons have you been taught in good debugging?
- What was the most difficult debugging session you've ever experienced?
Let's chat
Not gonna lie, I still have a *lot* to learn about proper debugging that isn't just throwing out logs. I am going to get there, but when it comes to JS, good debugging sniffs out weird behaviors. #devdiscuss
#devdiscuss
I got a lot of thoughts on this topic.
1) Reproducing the problem is key. If you can't reproduce the issue, it's harder to figure out what's going on and iterate on fixes. More importantly, if you can't repro, you probably can't prove that a "fix" actually works.
Honestly, I wish debugging was the FIRST thing people were taught when they learned to code. I remember JavaScript made literally 0 sense to me until I was taught how to debug.
#DevDiscuss
I always start with setting a break point at the earliest entry point and then begin stepping from there. +100 if I can start from a unit test and step my way through. #DevDiscuss
1. debugger;
2. Async doesn't care about your console logs
3. Caching n-number of multiple related server calls while managing their loading state because someone set up rx.js to manage a monolithic model that updates ad hoc inside of an angular event loop.
#DevDiscuss
Welcome to #DevDiscuss
Tonight's topic is debugging!
Questions to start us off:
- How do you debug effectively?
- What lessons have you been taught in good debugging?
- What was the most difficult debugging session you've ever experienced?
Let's chat
I start debugging anything I don't know. I actually post a blog post about #a11y where I step people through what I am doing and why I am doing it. I have all the console.logs in there. https://t.co/r1cDEmtfPb#DevDiscuss
2) Error messages and stack traces are important. @swyx quoted me in a Dev post last year on this topic:
https://t.co/6bJUtCnwCx
They usually give you a good starting point for where the problem is and why it's happening. Read the messages. Google them if needed.
#devdiscuss
Know how to use a good IDE and how debuggers work in general. Arbitrary print statements are less helpful unless you have nailed down a problem *very* well. #DevDiscuss
Welcome to #DevDiscuss
Tonight's topic is debugging!
Questions to start us off:
- How do you debug effectively?
- What lessons have you been taught in good debugging?
- What was the most difficult debugging session you've ever experienced?
Let's chat
#devdiscuss Used to dry run a lot on paper when I was new. Not so much now. Printing out values between methods, loops or any such structure has been a good debugging strategy for me. Using IDE debuggers to help track logic flow and any semantic issues has also come in handy.
I had a mentor that taught me a ton about debugging. He would spend hours stepping through code to get to the root cause of an issue. The biggest lesson I learned from him was to create a quick unit test that allowed you to step through the code. #DevDiscuss
Personally a huge fan of binding.pry when I am working in #ruby to help me debug.
If I am working with a service like Elasticsearch or Redis I always head straight for the logs! #DevDiscuss
Look at the stack trace. It's like a bad crumb trail to where it all started. And in the context of Chris DevTools, it'll bring to the spot in the source code that relates to what you clicked on in the stack trace. #devdiscuss
My favorite debugging tool of all time is shell_plus for @djangoproject (part of django-extensions). You can set it up to use iPython, or even an Jupyter notebook. It imports a bunch for you so you don't have to do that every time.
#DevDiscusshttps://t.co/Jx701n0AwQ
Welcome to #DevDiscuss
Tonight's topic is debugging!
Questions to start us off:
- How do you debug effectively?
- What lessons have you been taught in good debugging?
- What was the most difficult debugging session you've ever experienced?
Let's chat
3) Know your tools. Most debuggers work the same no matter what IDE / DevTools you're using. Understand breakpoints, watches, stepping. Use more advanced features like conditional breakpoints, or "watchpoints" to just log a message instead of stopping.
#devdiscuss
I actually dealt with this today when I was debugging d3. Had no idea how to reproduce the issue. Turns out I was screwing up my scaleTime and the line graph was going off the page. Whoops. Wish I had strategized debugging earlier in my day!
#DevDiscuss
If you have ever had to debug a distributed system then you know difficulty and pain. This is one downside of microservices in my mind, if you have an issue that is not isolated to one, you need to debug through multiple hops which can be a huge challenge. #DevDiscuss
I love that you can blackbox certain libraries or files and they'll never show up in a trace to distract (eg react-dom, react-dom, moment.js). Meaningful error messages thrown from your interfaces/components when an error is caught will help immensely. #DevDiscuss
I'm still learning how to use debugger; in JS. I really like using Chrome DevTools to set a breakpoint. It's really useful, particularly to ensure events are firing.
#DevDiscuss
4) But sometimes an IDE debugger won't cut it, especially if it's a remote system or multi-threaded environment. Good ol' console/print debugging is still important. It helps to have lots of existing logging with different levels that you can enable via config files.
#devdiscuss
Good debugging is systematic—like a word search puzzle.
In word search you skim down each line looking for trigger letters to complete the word. Don't go freestyle and skip steps.
In debugging you can often systematically eliminate variances until THERE IT IS.
#devdiscuss
100% agree! Being able to reproduce the error makes it infinitely easier to fix. The hardest bugs to crack for me have always been ones that I struggled to reproduce because I didn't even fully grasp what is going wrong in the first place. #DevDiscuss
Learning to use a command line debugger is worth it, as a supplement to our replacement of any GUI debugger. I always hated the unexplained "you can't do that here" with GUIs, and they're all mostly just front ends anyway. #DevDiscuss
To be honest, my debugging skills are trash. My debugging so far has mostly been logging code, commenting things out and walking it back, and trial and erorr and just re-writing stuff. Proper debugging is a priority for me to learn in 2019. #devdiscuss
5) Go in with a hypothesis. Understand how the code _should_ behave first. Look at the actual behavior. You can probably make educated guesses for where things are diverging. Focus on those areas. Don't randomly tweak. Change _one_ thing at a time and compare results
#devdiscuss
Debugging. Once I learned I wasn't limited to just using log statements for debugging, life improved greatly. But, sometimes, simple logs are all you need. #DevDiscuss
For python, I am a huge fan of ipdb, it is the greatest thing since sliced bread. Then again, lately my work has been ML and research focused. So I don't have to worry about debugging much. A lot of the production type code is handled by someone else i work with.
#devdiscuss
Good debuggers help you to ask the right questions in the worst case, and in the best case they show you exactly what the problem is. Almost as good as a program (xdebug, chrome dev tools) is another person. Often they can spot the issue while you're tunnel-visioned. #DevDiscuss
6) Experience helps, but don't be afraid to dive in if you're new, because that's how you get experience :)
Finally, my best debugging story: the time I spent 6 hours digging through code, before I finally changed the case of _one_ letter:
https://t.co/YOhwZCgMMJ#devdiscuss
Dev Tools has become a good friend when I am doing any debugging. As I keep coding, I find myself not only using it more but I take my time to read what appears in the console when I run my code so I can understand what the error messages are telling me #devdiscuss
You know, now that I think of it. I have never really learned any industry standard techniques for debugging. When I used to write more deployable code, I just used print statements, ipdb, and spent a LOT of time picking apart and testing code.
#devdiscuss
Once you're a senior developer, most debugging sessions will include the phrase "wait, how did this *ever* work?"
Once you find yourself saying that often, ask for a raise.
#devdiscuss
Advice for debugging: DIVE IN!
During our coding interview half of what we want to see is how you debug. Some people try to work it all out in their head. I have never found that to work well. I like to see people attack the code, puts statements, break points, etc!
#DevDiscuss
#devdiscuss the most important thing that I've been taught about debugging is that most bugs are introduced because of assumptions that aren't true. My fav method is to go line by line, ask "what am I assuming here?", and verify that those assumptions hold.
🦆 Rubber duck debugging is a life saver. Don't dismiss this technique.
Put a rubber duck on your desk and when you get stuck, explain to the duck how your code works step by step. You'll find the cause of the issue b/c you just explained how it SHOULD work.
#devdiscuss
Welcome to #DevDiscuss
Tonight's topic is debugging!
Questions to start us off:
- How do you debug effectively?
- What lessons have you been taught in good debugging?
- What was the most difficult debugging session you've ever experienced?
Let's chat
Most useful thing about a proper debugger: seeing what the local/global values are for the context you are running in. So many small things can be caught just by looking at those as you step through your code. #DevDiscuss
Okay, one more.
7) Persistence is good, and it takes time to build up mental context on an issue, but sometimes you gotta take a break. Plenty of times I've left work, gone home, relaxed, and figured out what the issue was overnight or in the morning.
#devdiscuss
Best I can say is to write code with expected results and implement test driven development. Going so far as to write unit tests BEFORE you write code. Thinking critically about what your code should do helps a lot when it does something it shouldn't.
#devdiscuss
I think I rubber duck literally every day now. I'm learning d3 while parsing through some nested data structures. I only solved an issue today after talking to my boss (the rubber duck here).
#DevDiscuss
If you're having issues debugging an issue in regards to latency, changing the network speed in the @ChromeDevTools is a great way to simulate that. #devdiscuss
Now for debugging ML. It is kind of an weird concept since ML models by their nature are uncertain. There is a whole world of validation, hold out sets, and theory you can get into to make this happen.
#devdiscuss
The most painful debugging problem I have faced: exhausting the thread pool on a web server. This was painful because it wasn't obvious that it could happen looking at the code. Until you realized that the code was spawning one thread per fetching of an item from S3. #DevDiscuss
Welcome to #DevDiscuss
Tonight's topic is debugging!
Questions to start us off:
- How do you debug effectively?
- What lessons have you been taught in good debugging?
- What was the most difficult debugging session you've ever experienced?
Let's chat
Also, shout out to Fiddler for any devs on Windows. That tool was invaluable to me when I was on a Windows machine. Changing network conditions, replaying/modifying requests etc. Thanks for such a great tool @ericlaw! #devdiscuss
In reply to
@ThePracticalDev, @ChromeDevTools, @ericlaw
I was doing front end dev for Drupal and only had to turn on xdebug once every 3 months and I always forgot how to configure it. But, yes, it is TOTALLY fire once you have it set up!
#DevDiscuss
The best thing you can do is to have some kind of qualitative output you can continually moniter. For example, if you are running a tweet classifier, have a log that shows what its most confident positives and check it every so often .
#devdiscuss
COMMENTS ARE SO IMPORTANT
But the hardest lesson to learn is how to comment code correctly.
Too terse is no good.
Too long is no good.
There's a nice middle place that highlights the goal and process of your code, not just a blatant rehash of method names.
#devdiscuss
I am truly bad at using debugging tools. I'll reach for them when I am have absolutely exhausted my capabilities with print statements, but they never stick.
I'm always back to printing lines the next day.
#DevDiscuss
In addition. Make sure all of your training is well documented and repeatable. Ideally with just one script. I can't count how often I've had models and servers break because scikit-learn changed it it handles floats or unicode.
#devdiscuss
I've tried it on a Mac,but it's just buggy.The UI crashes a lot. Nothing related to Eric's work. I think it's the fact that it's not running .NET,but mono?I'd love to see it ported to .NET core so that it could run really well on non-Windows environments. cc: @Telerik#devdiscuss
In reply to
@ThePracticalDev, @ChromeDevTools, @ericlaw, @Telerik
#devdiscuss The most challenging debugging work for me has been reading and fixing someone else's code. Without the right comments or proper structure it was hell unleashed. Had to pretty much start from scratch. Took much longer than it had to. So dev folks - comments pls! :)
How I usually debug
1. Start at the bug & set a breakpoint
2. Work my way backwards. Set break points at critical places of the code
3. Step though the code and keep an eye out on important variables
4. Once I identify the problem, I examine it more and try to fix it
#DevDiscuss
This is me as well! I’ll also do a “binary search” and put a breakpoint halfway through the code to check if my values are expected. This helps eliminate stepping through parts of the code that are working properly. #devdiscuss
I always start with setting a break point at the earliest entry point and then begin stepping from there. +100 if I can start from a unit test and step my way through. #DevDiscuss
I heard a SpaceX employee tell me about a time they spent months hunting down a small bug IN A SPACESHIP.
I think spaceship debugging is probably more stressful than my day-to-day. #DevDiscuss
And that's exactly why I never say what I'm really thinking when writing debug code. Years in the newspaper industry taught me that the funny, for-placement-only headline you write is gonna make it to print someday... #devdiscuss
I’ve made a particular effort to improve at this. That means I’ve taken the time to learn how to use dev tools better and when I find myself logging out a lot, I stop and find a better way. I still use logging out frequently, but it’s not my primary tool. #DevDiscuss
I am truly bad at using debugging tools. I'll reach for them when I am have absolutely exhausted my capabilities with print statements, but they never stick.
I'm always back to printing lines the next day.
#DevDiscuss
I've poked at DevTools, gdb, NYTProf and other tools, but most of the time, I find it quicker and easier to debug with print or console.log.
#devdiscuss
Starting a new project? Take detailed notes on how to configure the local/production env. Links, screenshots of articles, blogs, and stack overflow that got you to Hello World, htaccess and url rewrite, any and all of that.
It's clutch for future you and coworkers
#devdiscuss
The most difficult debugging sessions I've ever had have all been race conditions. It's incredibly frustrating to debug something you can't consistently reproduce #DevDiscuss
Welcome to #DevDiscuss
Tonight's topic is debugging!
Questions to start us off:
- How do you debug effectively?
- What lessons have you been taught in good debugging?
- What was the most difficult debugging session you've ever experienced?
Let's chat
Analyze the issue, write a test (TDD) that covers the issue.
Best lesson is don't touch the code until you understand the issue, and have an approach after the TDD part. #DevDiscuss
For me, debugging 🐜 effectively starts with a reproducible scenario; the steps to recreate the issue 🚶. From there, patiently searching for clues for “threads” to pull 🧵. After enough searching, one of those threads always seems to lead to the root cause 🌳 #DevDiscuss
Welcome to #DevDiscuss
Tonight's topic is debugging!
Questions to start us off:
- How do you debug effectively?
- What lessons have you been taught in good debugging?
- What was the most difficult debugging session you've ever experienced?
Let's chat
I used to be the lead dev on an election night dashboard app -- you can test as much as you want with fake data and no users, but the real data comes in for the first time at the same time everybody is using the app. Pretty stressful.
#DevDiscuss
I have some thoughts on debugging production.
1) Looking at log files is a great practice. If you have a cluster of servers though, setup a log aggregator. That way you can view logs across multiple servers on the same timeline. #DevDiscuss
Most difficult debugging session?
Anything involving a race condition! Mainly because they are hard to reproduce and you have to really understand the code in order to find them. #DevDiscuss
If you're too deep in the weeds with a bug that's frustrating you, a few minutes away from the screen works wonders. Take a short walk, talk to someone about it, or let it sit overnight.
#DevDiscuss
2) Try to tag your log files with some info about the user, tenant, request id, anything you might find useful later. This is helpful when you’re tracing a problem through multiple requests. #DevDiscuss
3) If you’re debugging slow database queries, use the EXPLAIN and ANALYZE features. It can be tough to reproduce without production data, so try to look at the query plan to see what’s going on. #DevDiscuss
4) If you’re debugging a problem for one of your users, practice asking good questions. Your customer doesn’t speak the same way you do, but you still need to get valuable information from them. #DevDiscuss
Sometimes you gotta go old school with a pen and paper or go on a whiteboard to get your thoughts flowing. Also, do not be shy to ask someone for help. Doesn't matter if you're a junior or senior. It's always OK to ask for help. #devdiscuss
5) don’t be afraid to go back to the basics. You don’t need the fancy debugging tools all the time. Print statements, a simple test can work just as well. #DevDiscuss
My worst debugging sessions..
Why isn't this working? It was working yesterday. Hey, my nice co-worker help me with this. No, you don't see anything off?
(several hours later)
oops was pointing to an older version of the database 🙃
#devdiscuss
I think a lot of debugging skill comes from experience. Once you encounter an issue its easier to recognize the second time around. Just keep attacking things head on, eventually it will get easier 😃 #DevDiscuss
One tough debugging session - C++ optimizer was tossing out code that it thought was not being used (it was being used, weird double pointer initialization faked out opti) So worked fine when debugging and only failed in release mode #DevDiscuss
6) Debugging a production issue is all about eliminating what it could be. Try to think it through and ask, “Is the problem here?” Trust your intuition but don’t become fixated on something without evidence to back it up. The problem could be anywhere. #DevDiscuss
I tend to compose an email/message to the product mailing-list/forums as my rubber duck. Feels like 80% of the time, my own documenting of how to recreate the issue leads me to catch my problem and I end up not actually sending the message.
#DevDiscuss
In regards to asking for help, do some work up front first. Going to someone and saying something doesn't work or that there's a bug is not helpful if you're looking to get assistance from someone. #devdiscuss
Gut checks are my favorite. If I am stuck on something, I always tell someone my instinct and ask if that sounds right. Sometimes they will suggest a different approach and the lightbulb goes off.
#DevDiscuss
Sometimes you gotta go old school with a pen and paper or go on a whiteboard to get your thoughts flowing. Also, do not be shy to ask someone for help. Doesn't matter if you're a junior or senior. It's always OK to ask for help. #devdiscuss
In vanilla JavaScript, I'll use the debugger. It's buggy with React so I use console.log for logic and borders/bg colors for visible components
I use pry for Ruby or puts, depending on where the code is
Mainly though, a lot of printing and googling
#DevDiscuss
Welcome to #DevDiscuss
Tonight's topic is debugging!
Questions to start us off:
- How do you debug effectively?
- What lessons have you been taught in good debugging?
- What was the most difficult debugging session you've ever experienced?
Let's chat
It's really fascinating to me to see the differences in backend and frontend debugging stories. I have no idea what the backend folks are talking about but it sounds super cool.
#DevDiscuss
AGREE! Walking away is hard when all you want to do is solve it but even just going to grab a snack while you let your mind wander over the buggy code can be super helpful #DevDiscuss
In reply to
@sunnysinghio, @pandyzhao, @ThePracticalDev
Gut checks are my favorite. If I am stuck on something, I always tell someone my instinct and ask if that sounds right. Sometimes they will suggest a different approach and the lightbulb goes off.
#DevDiscuss
Sometimes you gotta go old school with a pen and paper or go on a whiteboard to get your thoughts flowing. Also, do not be shy to ask someone for help. Doesn't matter if you're a junior or senior. It's always OK to ask for help. #devdiscuss
I just want to say I am so thankful that debugging tools are built into IDEs and have mostly the same commands. I remember chasing seg faults in C with gdb. WHEW!
#devdiscuss
but throwing out logs is so easy and fruitful! While I do use pdb for my Python, it's easy to add debug print-statements with sequential numbers as I expect to see them and it traces my progress before things fall over.
#DevDiscuss
Lessons? I don't know. Not a lot I guess, now that I think of it. I've been told to use tools vs print statements but that's mainly it. I guess I'll scour the hashtag and see what's suggested
#DevDiscuss
7) like most everything, debugging is a skill you improve with practice. Enjoy it. It’s a great skill to have. With practice you can learn to trust your gut. Stay calm. Production issues can be scary but you need a calm brain to solve them. #DevDiscuss
One that's mentioned a lot for problem solving that definitely applies to debugging is if you've been at it for a while making no headway, step away to clear your head. You generally come back and figure things out #devdiscuss
debugging can be so multilevel. Print statements or gdb + valgrind can uncover an error, or a flaw in the design of the system can make all attempts to solve it fruitless without going outside the code. TLA+ is a nice way to kill some of those design bugs I hear #devdiscuss
Sometimes you gotta go old school with a pen and paper or go on a whiteboard to get your thoughts flowing. Also, do not be shy to ask someone for help. Doesn't matter if you're a junior or senior. It's always OK to ask for help. #devdiscuss
If you're using a frontend framework, get super familiar with the dev tools for it -- Vue, React, and Redux all have awesome Chrome extensions. Augury for Angular looks pretty promising too.
#DevDiscuss
Well I guess one self-taught lesson? If I google it and I don't see a lot of fanfare or other people having similar issues? It's probably i-d-10-t error vs being a legit issue 😂
#DevDiscuss
I can't tell you the number of times I have put in a debugging break point, fixed the bug, then run the test suite and sat there for minutes wondering why the tests didn't complete 😂 #DevDiscuss
The biggest lesson I've learned when it comes to debugging is that sometimes you need to take a break. There have been many times where I had let it go and back with a fresh perspective. I find the bug pretty soon after. #devdiscuss
This was async tasks. It was bad, easy to see once you found it, but painful getting there. Long story short, limit the number of tasks you spawn. #DevDiscuss
#devdiscuss it sounds rudimentary, but the most powerful tool in your debugging toolbox is to be able to read and understand a stack trace. sometimes, half the battle is being able to understand *what* blew up rather than how it did. The how is usually obvious.
I agree, debugging is an important skill for all devs and the only way to learn is by doing. You will eventually start to recognize specific bugs and know how to fix them quickly and easily. #devdiscuss
In reply to
@littlekope0903, @nickytonline, @ThePracticalDev
#DevDiscuss Reproducing the bug, ideally with a failing unit test, is essential.
If you don't have enough info reproduce it, adding logging might help, to see what else happens before or after the bug. At least it might help narrow down which part of the system the bug is in.
Printing lines of dashes/dots/equal signs and things like "variable_name is:" can be sooooo helpful when there's too many lines outputting for my brain to keep up with.
#DevDiscuss
Jet brains breakpoints are great for 1) learning about code that isn’t yours and 2) obviously, debugging. Hardest debugging session was a problem that was tough to reproduce and had to do with some programs opening too many connections and crashing in certain cases #DevDiscuss
When it comes to build engineering, if you're like me and use a lot of bash/GNU/*nix tooling, knowing the different commands and their verbose switches is a life saver #DevDiscuss
I will say the best thing I probably do as far as debugging is using react dev tools. I feel comfortable using react dev tools to ensure that my components are behaving as expected. I've become accustomed to checking state, props, and other things through that tool. #devdiscuss
Most difficult? A recent session where I had several sets of tests with models and model-tests but then also be able to do all the same stuff via an interface. Me being the intellectual I am, ran each set of tests separately, without checking for regression
#DevDiscuss
Very minimal debugging experience through school, but I start my first full time web dev job next Tuesday and am excited to learn proper techniques! #DevDiscuss
Audio debugging is challenging because it's ephemeral. Soon as you put a breakpoint in, the audio disappears. Can't print debug audio either. Grinds to a halt. There's some techniques you can use to mitigate the issues but sometimes it's listening. Very carefully. #DevDiscuss
The tried and true way to debug for me is to step through every 👏 line 👏 of 👏 code 👏. Time I'll never get back was wasted on bugs I was too impatient to catch the first time through. Can't speak on experience outside of JS and C#, but srsly. Step through it all! #devdiscuss
Tips for debugging (in React):
- look at the stack trace (if there is one)
- narrow the problem down to the component
- console.log() state/props
- narrow down more
Most of the problems I ran into this week had to do with state/data from props not resetting #DevDiscuss
Welcome to #DevDiscuss
Tonight's topic is debugging!
Questions to start us off:
- How do you debug effectively?
- What lessons have you been taught in good debugging?
- What was the most difficult debugging session you've ever experienced?
Let's chat
#DevDiscuss Continually narrowing down the possibilities of where or what the bug could be is the general process.
That could be what class or user action causes it, or it could be in terms of what commit caused it.
git-bisect is great for the latter: https://t.co/xBzSBj6IrW
Conditional breakpoints are very handy. They're supported in Chromium based browsers/Electron and @code (probably other editors as well). It's been a while, but I believe Visual Studio supports this as well. WebStorm?
https://t.co/HycZD36JMThttps://t.co/O36Weu2Lm2#devdiscuss
We are working in @vuejs for our current projects, and I’m really impressed with their developer tools and elaborate error logging. It’s awesome when the developers of a framework think about their users! #DevDiscuss
So at the end, I'm feeling triumphant ready to run the whole thing, and it's not all green and I'm worn out and extremely confused. Luckily, once I read the errors, it wasn't bad. That whole challenge was my most difficult session 😂
#DevDiscuss
Had to learn how to regex in like a day. The whole thing was an ordeal but I'm so glad I did it. Was definitely riding high there when it was all done
#DevDiscuss
👇👇👇👇👇👇👇👇👇👇👇👇 👍
(it's why i use gitnotes religiously, even if it is to vent a couple good "modafawkas"... it helps me remember better the whole process)
#devdiscuss
The biggest lesson I've learned when it comes to debugging is that sometimes you need to take a break. There have been many times where I had let it go and back with a fresh perspective. I find the bug pretty soon after. #devdiscuss
Pairing up and talking through things can be really helpful when debugging - I’ve often hit a wall where I’m out of ideas and have thoroughly confused myself about what’s happening. Having another person to talk things through, can help give a new perspective! #devdiscuss
One of the best ways to help others find their own bugs is by asking questions during a PR review! If a PR involves code you aren't familiar about, ASK about how it works! I have found so many bugs in my own code through other's questions #DevDiscuss
This is really great! Plus you get to see how someone else debugs and that can help you pick up pointers or techniques you might want to start using yourself #DevDiscuss
My Learn AWS By Using It course if flying off the shelves. Made some updates to the course last week that streamlines things a bit. If your looking to get into AWS, check this out. More updates coming this year, free to all customers https://t.co/8HBXfPNqkK#DevDiscuss
