Stephen Reader

Can someone explain to me how to get "more experience"? I have 16 years of full stack software engineering experience, mostly in C# .Net 4.2 through 8, including .Net Core 2.x & 3.x, along with WCF, WPF, Winforms, Razor/Blazor, HTML, CSS, and JavaScript, with Entity Framework, Dapper, Linq, SQL Server, MySQL, SQLite, Oracle, NoSql, and other databases. And a few of those years include a combination of Java, PHP, and C/C++. I've also used MarkDown, PowerShell, MVC framework, Swashbuckle/Swagger, Newtonsoft, JSON .Net, TopShelf, and a variety of testing frameworks. But apparently that's not enough. In the past 3 years alone, I've learned ReactJS, TypeScript, Xamarin, XAML, Maui, NodeJS, Terraform, AWS, and Azure, and I'm currently learning Angular, but that doesn't cover the 3-5 years of experience jobs want. I've learned some of these skills through jobs, but also some on my own. Except that as often as companies want us to learn these skills outside of work, they only count professional experience when it comes to hiring. My last interview said I needed more experience, as if the previously mentioned 16 years wasn't enough, and neither was the 15 years of computer repair and networking before that, which their interview questions also covered. So if no one is willing to hire because people don't already have experience, how are we supposed to get the experience? And don't say "open source projects", because they don't count as professional experience. Or do I have to take a 50% pay cut to take an "entry level" job that still requires 3-5 years of experience that I somehow still don't have? People are quick to say that "no one wants to work anymore" when they can't get hired, but they never seem to think "businesses aren't willing to teach anymore" when they refuse to hire people. Why? Is it that we are so conditioned to think that it's always the individuals fault for not living up to expectations, instead of the businesses fault for setting unrealistic and ever changing expectations? So, I ask again, how can I get the required experience when employers refuse to hire unless I already have experience?

2

my favorite thing about next.js is that webpack is already configured. I enjoy the developer experience. I like the api/routing system - it makes sense to me and I like not having to configure it. I like that they have a boilerplates system for server side rendering #NextJs #React #Framework #WebDevelopment

10

learned about *ngIf && *ngClass today. once i figured out that angular checks component state and by modeling the chess game and storing state in a nested in a typescript object I was able to get this effect. Its Clicking!!!

6

Automate your build & test with GitHub Actions they said. It'll be easy they said... That was 90 minutes of head scratching, mild cursing, and reinforcement of my belief that somebody other than me needs to be responsible for DevOps matters on any project I'm on. I do NOT have the right mind for this kind of work, and I get frustrated WAY too easily. The workflow is actually working now, but it was a SLOG to get there, and it was failing for (to me,) a stupid, stupid reason. Windows doesn't care if your directory and file names are cased differently from the way they're expressed in the solution or project files. Linux, on the other hand, loses its open source little mind. //TODO: Add another coding standard to the list, and find a way to lint this stuff, hopefully in an automated fashion. See y'all tomorrow. - #thatDeveloperDad #figuredItOut #liveCoding #liveBuilding

6

10 Comments

After finishing my SWE bootcamp, I thought I knew how to work with React. Boy, was I wrong—I merely knew just enough React to barely get my foot in the door. Early on, in my first job as a React developer at a software agency, I still vividly remember getting publicly scolded on Slack by far more experienced developers when I submitted my first couple of PRs. My coworkers made it very clear that my approach to coding was more like swinging a sledgehammer at a problem when a more elegant and refined approach was needed. I’m not ashamed to admit I didn’t take nearly enough time to think about the rest of the development process... because I never had to before. These kinds of mistakes are easy ones to learn from, and I never made them again. I think it’s safe to say you’ll learn far more every month working as part of a team than you can in six months on your own. If you’re out there looking for your first job, I can’t recommend strongly enough finding other developers to work on projects with. It’s one thing to learn how to center a div; it’s another thing entirely to KNOW you’re not uncentering another one. #react #javascript #typescript #softwaredeveloper #juniordeveloper #css #centeradiv #softskills #teamskills

23

5 Comments

Junior developers are inherently risky (in every industry, not just tech btw). "𝘉𝘶𝘵... 𝘐 𝘢𝘮 𝘢 𝘫𝘶𝘯𝘪𝘰𝘳", you say. Yeah, I get it, I get it, just bare with me here. The word "junior" is so subjective that it's nearly meaningless. 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗯𝗮𝘀𝗶𝗰𝗮𝗹𝗹𝘆 𝗯𝗼𝗶𝗹𝘀 𝗱𝗼𝘄𝗻 𝘁𝗼 𝗶𝘀 𝘀𝗼𝗺𝗲𝗼𝗻𝗲 𝘄𝗵𝗼 𝗵𝗮𝘀 𝘀𝗼 𝗹𝗶𝘁𝘁𝗹𝗲 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝘁𝗵𝗮𝘁 𝘁𝗵𝗲𝘆 𝗰𝗮𝗻𝗻𝗼𝘁 𝗯𝗲 𝘁𝗿𝘂𝘀𝘁𝗲𝗱 𝘁𝗼 𝗱𝗼 𝗻𝗲𝗮𝗿𝗹𝘆 𝗮𝗻𝘆𝘁𝗵𝗶𝗻𝗴 𝗼𝗻 𝘁𝗵𝗲𝗶𝗿 𝗼𝘄𝗻. • They need significant hand-holding for months on the job. • They will take on the easy stuff and maybe break some things. • They won't contribute much. 𝗛𝗲𝗿𝗲'𝘀 𝘁𝗵𝗲 𝘁𝗵𝗶𝗻𝗴: nearly every developer will be "junior" when they first join a company unless they are very senior. You don't actually need to a be a mid level developer to be a safe hire. You just need to avoid the tell-tale signs that you are, in fact, a n00b. Quite simply, stop down-playing yourself. • 𝗥𝗲𝗺𝗼𝘃𝗲 𝗷𝘂𝗻𝗶𝗼𝗿, 𝗮𝘀𝗽𝗶𝗿𝗶𝗻𝗴 𝗮𝗻𝗱 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 from your resume and LinkedIn. • DON'T talk about "the project from your school or bootcamp" • 𝗗𝗢 𝗧𝗮𝗹𝗸 𝗮𝗯𝗼𝘂𝘁 𝘁𝗵𝗲 𝗮𝗽𝗽 𝗼𝗿 𝘄𝗲𝗯𝘀𝗶𝘁𝗲 𝘆𝗼𝘂'𝗿𝗲 𝗹𝗮𝘂𝗻𝗰𝗵𝗶𝗻𝗴 - yes, you need to have a project to talk about. • 𝗨𝘀𝗲 𝘀𝘁𝗿𝗼𝗻𝗴 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲 𝘁𝗼 𝘁𝗮𝗹𝗸 𝗮𝗯𝗼𝘂𝘁 𝘆𝗼𝘂𝗿 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 and speak to the benefits of features you created. • Instead of "created a full stack app with a laundry list of tech" try "migrated a JS app to Typescript to improve developer experience and velocity".

573

62 Comments

In over 20 years and many companies (check my profile!) of doing this, I’ve never found that there is a single “right” way of doing things. Some companies are very risk tolerant. Some are very risk averse. Some demand clean, supportable code at all times. Some just need to get it shipped as soon as possible. If you’ve only worked one or two places, you may think that the way they do things is the right way. That’s a jr dev mentality. Be open to the idea that there may be a sound reason for doing things a different way.

5

If you are a developer who likes hobby projects, I have a couple tips for you 1. sqlite is awesome. super easy for testing simple web apps and things that you want to use a database but not necessarily setup a database service 2. docker is great if you use it to quickly try out off the shelf software / run local services. for example, serving web applications locally is a lot easier if there is a pre-made docker container 3. Everything is an API. For hobby projects, consider tools like firebase or supabase that make it easy to integrate with services that are out of the box like a database rather than hosting everything yourself. (openai is a huge example of this, use openai if you want to do LLM stuff since they wrap it all for you with an api) 4. follow #3 sparingly - other people hosting things is convenient but can be expensive $$$ 5. follow people you like on twitter / linkedin / etc to stay up to date with cool technology. I learn a ton lately online from other makers. Much more than I ever learned from reading coding books or taking courses :) 6. build stuff often and try things instead of reading all day about how you COULD build it. Building it for real is harder and you will learn more

12

2 Comments

It's so disheartening to see the way predators are circling the developers coming out of bootcamps and other "get rich quick" themed "training programs." As has been said, many of these bootcamps push devs out with little to no real skills into companies who have already agreed to put in a great deal of "on the job training" *because they know you're vulnerable.* When you come out of a bootcamp, you *are not* ready to work and they *know* this. With the advent of narrow AI making this grift even easier to sell, since they can hand these new devs something that makes their programs "work" and shove them out the door, I'm genuinely worried for what's going to happen to the developers coming into this environment. If you're feeling alone and afraid, I do not want to be the person telling you to "stay the path, it's going to be okay." You could have been, or could be vulnerable to be, manipulated by these sort of people. A career in tech is something that's going to take you years to set up, at the very least, and if you can't make that kind of investment, you're going to need to find a way to feed yourself in the meantime because there are sharks circling you *everywhere*. I love this work. I love what I do. I know this is a good career and some people are going to be very happy doing it. If you *aren't* happy doing it, you shouldn't. Do not believe people who say you can get in and make tons of money with very little training, because they're *always* selling you something. Do the work. Put in the hours. Build the tools. Don't believe anyone who tells you it's easy. You can make it, but there aren't shortcuts.

14

4 Comments

Last week… I broke main… But I also fixed it 😅😂 A quick list of the happenings 1. Had no idea I broke it until the #firebase hosting link was a big ole blank page. Was reminded that the dev version in locahost and the build version have their differences 😅 2. That you can locally build a project and being able to reproduce that bug in the local build does allow for truths to be found and direct your problem solving and troubleshooting 3. Merge conflicts are annoying but they also would have been good moments to catch the broken preview deployment 4. Teammates are awesome, they will support and throw great ideas your way AND THE MAIN PART 5. When your app it configured in #Vite to with a #PWA rollup you better check your vote.config.js file to make sure as you added #Bootstrap all that was configured properly but ALSO check the manual chunking logic and make sure the chunking makes sense, like #ReactBootstrap and one of its dependicies actually end up bundled together instead of just in different bundles just mad at you and each other 😭🤣🤦🏽‍♀️ So eventful, I did break main already so it will never happen again correct? 😅😂 #SoftwareEngineer #Coding #WomenInTech #BlackInTech #SoftwareDevloper #Collbie The Collab Lab

10

2 Comments

ChatGPT replaces a junior dev in EVERY way. It's totally awesome and a bit funny too. If you work with dev's then you will get this experience I had today. (I understand this could be hard to follow otherwise.) But it's so worth sharing for anyone else who might get it... I'm working with ChatGPT today who is really becoming a dev coworker of mine. It's really like a person in a lot of ways and is super helpful and can be fun to work with. ChatGPT plays the dev role to a "t". By that I'm including speaking with certainty and reluctant to admit it's code doesn't work. After debugging some code we were working on today inside the HubSpot CMS and using HubL and HubDB it became clear that my buddy ChatGPT was giving me a now() function that wasn't working with the "date" data type. When I went to update my new dev friend with a correction to use today() instead of now(), I get a response that made me smile. ChatGPT doesn't say "good catch, that was wrong". ChatGPT comes back and says this instead! "If it works better for your purposes" Unbelievable! It's like it is programmed to have the sassy attitude of a dev as well. Anybody else working with ChatGPT as a coworker? Noticing it has a bit of a personality?

1

Some notes about interview code screens So I've gotten to do a number of code screens now - as well as practice with leetcode and hackerrank. I've definitely experienced the good and the bad and perhaps the ugly. Certainly having a tool that actually works like an IDE is a positive - I had that once and it was setup to write a class implementation and junits. This was also one of the better of the problems - a fairly simple data and statistics question with fairly clear criteria. I missed one of the gotchas and figured it out a couple hours later - but it was a fair question that I should have gotten. The problem was enough to show that I could code and in java and write tests and follow a problem and do some debugging. I did a couple screens with hackerrank - I hate the stdin, stdout call a main framing - it really doesn't fit normal java well. I also dislike the lack of a place to write junit code. And even the logging isn't consistent from the point of troubleshooting. One good screen was way too simple, but I was assured by the interviewer that they had a number of candidates fail. And perhaps not just because hackerrank is weird. I was offered up a different problem with hackerrank, twice at the same company. And it was to write code using built in java libraries to do things that you would only do with libraries. I talked my way through the problems and the issues but it was ugly. If I saw a pull request with code hand-written to process json or using base java code to do an http request, I would have put a hold on that code change. I did another code screen using my own IDE. It was pretty good, though but it wasn't pure logic so it showed what I might have done on a first pass with java. Unfortunately no one likes anyone else's code style - it is kind of why I write code in "house" style - and help companies create a "house" style. I'm thinking on the interviewer side, it is important to figure out why you are doing a code screen and what you are trying to screen for. If you are hiring for a strictly coding role, it might be interesting to ask about different aspects of a language and then have the candidate demonstrate those aspects if they are important to you. But you definitely want to avoid screening candidates out for not being able to demonstrate skills on the fly that they are not going to do on the job. On the interviewee side, it is important to be able to talk through the problem while you are coding. And to practice solving coding problems. Coding problems are not very like real-work and require a different set of muscles. But if you think coding is fun, than doing coding problems is more coding than most people do at a job.

7

4 Things You Should Put in Your Daily Dev Log To harvest meaningful patterns from your dev log, you’ll need to capture the same things daily. I’ve been engineering software for 25 years, and I’ll share what I’ve routinely kept in mine. Your context is different, so your list will be also. Just make sure you capture the same things daily. Use this list as a skeleton to start from. It’s easier when you aren’t starting from a blank page! Pull Requests I keep track of every PR I submit, approve, or merge. Almost any work product I deliver or review flows through Git. My lists of PRs serve as a personal task-level kanban board of work in progress that I am connected to. These help me easily reconstruct a story of what I’ve done throughout the week. Personal Interactions I make note of every personal interaction I have, scheduled or otherwise. In addition to these notes, I keep a page for each person, and I link to that page from my daily notes. As I note patterns of interaction with a person, I’ll describe those patterns on their page. Over time I build a library of every person I’ve collaborated with and what we worked on together. Project Actions I keep a running narrative of the things I’m working on. I keep a section for each thing I’m working on. These might be at the product or story level - it just depends. Each time I hit a stopping point or interruption, I make a note of what I’ve been doing and what I plan to do next. Guess what I use to inform my daily standup updates? Perplexing Puzzles I make a note of everything that surprises me. These could be strange program behaviors, blockers, production issues - anything unexpected. As I review these periodically, I ask myself how I can use what I’ve learned to improve my mental models. Hopefully this list helps you get past the starting line. Do this faithfully for several months and see where it takes you!

8

8 Comments

Brace for takes: Going into 2024 the snake has eaten its tail on SPA vs MPA setups. Server side rendering is all the way back, but with JS on the front and back end. For a decade React has been positioned as library not a framework, but that opinion has flipped. I recommend learning react as a framework instead of a library. You learn it either way, but the framework perspective is more relevant to the moment. Learning to use Next.js is your best target. https://nextjs.org/learn If you look for a tutorial or course, look for something that teaches you React / Next.js / Typescript If you are looking for an environment that encompasses all three look at PayloadCMS. https://payloadcms.com/ CSS whips right now. Nesting, scroll timeline, has(), color spaces... we are having fun over here. Spend your time working on CSS and not SASS. (You could look into Tailwind to supplement your React journey)

3

🚀 10 Signs You're a 10x Engineer (and don't even know it!) 🧑‍💻 1. You've googled "how to exit vim" more times than you'd like to admit. 2. Your commit messages are works of art. Sometimes they even rhyme. 3. You've fixed a critical bug by adding a single semicolon. 4. Your code comments are a perfect blend of humor and despair. 5. You've mastered the art of looking busy while waiting for your code to compile. 6. Your rubber duck has seen things no duck should ever see. 7. You can explain technical concepts using only memes. 8. Your coffee intake directly correlates with your git commits. 9. You've had heated debates about tabs vs. spaces. 10. You've written "it works on my machine" so many times, you're considering getting it tattooed. Bonus: You're reading this and nodding vigorously! 😄

82

17 Comments

One of the hidden perks of Go? It stops developers from engaging in epic battles over code formatting! You know the ones—fights over whether the opening brace should be on the same line or the next (who knew we could be so passionate about curly braces?!). Go settles these debates once and for all by enforcing a standard format. Tabs for indentation? Check. Braces on the same line? Absolutely, or it’s a syntax error! 🛑 Tools like go fmt make sure your code always looks just right, while goimports goes the extra mile by cleaning up and organizing your imports. So, instead of waging war over where that brace belongs, Go lets us focus on solving real problems—and keeps the peace among devs! 😅 #GoLang #DontFight #DeveloperLife #CodingBestPractices

9

Working with focus has always felt mysterious to me until I dug into it! I’ve been dealing with focus in my TCA template project for the various fields in my forms, so let me explain it to you. How does focus work in SwiftUI? SwiftUI provides the @FocusedState property wrapper to control and track which fields have user input. You can bind it to a Boolean to control a single field or to an enum to manage movement between several fields. If a caller sets the value to false or nil, SwiftUI automatically dismisses focus. SwiftUI also provides the focused modifier to bind the focus state to a field. Once you’ve set this up, your field is bound to the focus state. This approach allows for smooth navigation between fields and offers a way to programmatically control focus, enhancing the user experience in your app! What strategies have you used to manage focus in SwiftUI forms? --- If you're looking to improve your TCA skills, check out my free interactive tutorial on TCA best practices: https://lnkd.in/dJHaxm4E

9

2 Comments