I've always wondered - does full stack mean everything from managing bare metal to CSS?

circuit design up to rendering pixels in assembly code

Get back to me when you're pressing semi-conductor wafers.

It doesn't count if you're using hardware rendering either.

Maybe that's why DaveT can't find work

I moved to Seattle on August 1st.

Prior moving here I applied to 54 jobs and have been officially rejected by 29, assume I've been quietly rejected by 24 and received 1 offer, which I declined because it was an overall ****ty offer for the area.

Since moving here, I have applied to 69 jobs, officially rejected by 24 and am in the interview stage with none currently.

123 total resumes, 53 official rejections, at least 24 unofficial rejections and zero "hot" leads.

On the plus side, I have been attending quite a few meetups and I'm not a freak or a weird dude, so I'm meeting people and making connections. Unfortunately it seems about 2/3rds of the people attending meetups are bootcamp students or other job seekers, so they don't produce many great opportunities.

I get about 25% response rate for my resume for any kind of FTE work, whether local or remote. Of those, maybe 10% turn into an actual interview and / or take-home test.

For gigging, I'm probably around 5%, but the conversion is over 50%.

I have the opposite problem for now, but knock on wood. One of my clients is in Houston.

Meetups is pretty much that. Don't expect to get very far, but you may end up doing a presentation or two. If you have the opportunity, definitely do it, since it's a lot of fun.

Since it was brought up in my own list, are you staying focused on a single tech or are you sort of spreading yourself thin? I'm surprised there is so much work in the area.

Probably 75% of my applications have been to companies that use Ruby on Rails + some JS framework. The JS doesn't matter to me since I've used old Angular, Ember, and React. The other applications were just random shots in the dark hoping for a chance because I'd add a cover letter about being interested in what they are building.

Heh. I dunno. I usually search for "senior software engineer". I tend to think of it as "I can build web front ends in React.js and also build APIs/design DBs/use various frameworks/understand all the various stuff at the application layer on the server side.

But I would expect most people think of "full stack" as ending when you get to the part that gets described more as "Dev Ops", i.e. actually managing sever provisioning, Chef, containers, all that stuff. Which is still above the bare metal. I answered the question by saying "full stack development" because a lot of the openings I'm looking at use that terminology.

Yikes! We can be cheerful hobos together. In spirit, at least.

lots of jobs in northeast ohio. no hurricanes either. plenty of opioid deaths tho.

Cool - I guess I'm full stack then too. I've tried to get into docker and all that stuff but I just find it 90% frustration. I just can't get motivated to do POCs on my own although I can certainly edit a script once the system is up and running.

I need someone to throw me in and tell me to figure it out. There's a guy on our team who loves doing it. This is all on his own home system:

In my experience, "full stack" means "I know node"

lol Suzzer

I call myself full stack because I made a thing that is on the internet.

And I know node.

I spent the last 2 days debugging issues with deploying our java spring/hibernate locally on tomcat through vagrant, ended up escalating issues to our most senior guys and it has resulted in several updates to the scripts/docs that were wrong.

I love learning stuff and feel fortunate at the opportunity to learn java and a legacy backend.

Building stuff with rails and express seems like easy mode compared to this.

Discuss

99% of my debugging is using logs and console.logging things, debugger statements and chrome breakpoints are definitely a last resort for me. I barely use them.

LOL at getting worked up about people using then though. I think it probably takes on average longer to debug things when you use them first, but I definitely waste time being an idiot where a breakpoint would have shown me exactly what was wrong occasionally. Seems like a silly thing to get worked up about.

I've done a lot of debugging. It was basically my job description for several years. Some of it with interactive debuggers. A lot without. Invariably problems got fixed more quickly where it was possible to use more interactive tools. I have no idea why the tools that help you solve problems faster should be a last resort.

In my experience, otherwise competent people can completely suck at debugging. Just yesterday one of my engineers got stuck for a couple hours trying to write passing tests that kept giving 500 errors. She had put breakpoints all over the place and made no progress. So she asks for help getting unstuck.

I ask what's the error? A 500. Yeah but what's the exception that causes it? Dunno. Ok let's look at the logs.

Upon doing that it was maybe 2 minutes to find the two issues and correct them. All that time debugging and she hadn't even looked at the logs.

The whole ****ing job is debugging!

lol there are multiple use cases we have right now where I basically have to (without going through a world of hurt that's almost never worth it) debug purely with logs:
- native C++ code on android
- Unity C# code on mobile devices

Yeah, debugging is most of the job. Something that I have seen people do a lot is over-rely on inspecting the code. The code doesn't do what you think it does, looking at it harder is probably not the easiest way to resolve that.

The other day I was trying to figure out specifically what got called after a complex bash procedure constructed a command string and executed it. The person I was looking at it with wanted to trace the code back visually. I said "how about we just print out what it's actually trying to run, instead of trying to evaluate bash code in our heads"

Once it was printed out, the problem was pretty obvious/straightforward.

I have known a lot of people who do the "500 thing" above. They get an error, ignore it, change a piece of code at random, try again, another error, rinse and repeat.

The fun counterpart to this, though, is trying to debug (or coerce into reproduction) crashes you can't reproduce and just have callstacks/logs for. Code inspection is basically all you've got.

Reminds me of when I used to debug divergences (multiplayer game errors that would happen on a videogame I used to work on - it had a lockstep multiplayer model, where we transmit all players' input to each other and rely on each remote instance producing the same game state as a result, instead of transmitting the game state). We'd have logs spitting out the same output up to a certain point, at which point one of the users would diverge from the others and basically break the game (think of an old multiplayer game of Doom where one player looks to the other like he's just running into a wall forever, it's irrecoverably broken). Figuring out what went wrong from those logs was the most intense code flow inspection work I've ever done.