its cool that you are enjoying your bootcamp larry. I really liked mine too. I learned a ton and was pretty proud of some of the apps I made.

a lot of my enjoyment was tempered by the fact that I absolutely needed a job and all of the stress that arose from that. it sounds like you are free from such ulterior issues.

I definitely need a job bad once this is over. But I'm hoping it isn't very hard. I'm probably the most employable person overall in my group considering every factor in hiring. I came into this with a lot of existing experience.

Overall I'm probably the #2 person. The "best" guy does go to me for questions at times and I helped him with something he was stuck on for about 3 hours in 10 mins the other day, which felt nice. He is an absolute machine when he is stuck on something tho, he just will go into brute force mode and start trying any reasonable and many unreasonable combinations to solve things.

He was having an issue with correctly nesting .then's and some of the quick changes he was trying seemed nuts. Like there was no way some of the stuff was logical at all. I was trying to get him back on track by saying things like "if that change works my mind will be blown".

I'm way more likely to try and consult stack overflow to find the correct syntax than just trying tons of different combos to see what finally sticks. I feel like that's probably better in some situations and not in others.

I seem to be very good at looking at other people's code and understanding it. This also makes me somewhat lazy at times because I'll see someone implement a feature I like so I'll go to github to see how they did it.

Some stuff I'll make sure I do myself, but if it is not important to memorize the way to do something, and if I know I can find it two clicks away, I don't see why not.

Sometimes (maybe not in the context he was doing it) when you're having difficulty understanding or figuring something out, going down a level or two to make sure your fundamental assumptions about how things work aren't wrong can be helpful - so, writing some **** like "there's no way this should work" and making sure it doesn't (or the inverse, writing something super basic and making sure it does what you think it will) isn't always bad.

Not sure where I should ask about this, but has anyone used Shopify or alternatives?

ya, I often do this. if something is not working the way I think it should, I will change it so that it should most definitely fail, or output something really obv. and if it doesnt, then I know the problem is even deeper (or really the issue is on a more basic level.)

I do this too. I relate basic design and methods to previous stuff I have coded and then just copy and paste and change around the slightly different stuff. I figured that was how everyone coded.

and lol at not consulting stack overflow almost immediately. thats a huge time saver.

I use SO quite a bit, but probably only a few times a day, and it's never ever my first reference.

There was an interesting YouTube video I watched the other day, which is talks about using Real Books to learn music. While they are a good resource for immediately looking something up, the problem is that you never actually learn or retain information. If you sit down and learn the piece by ear, really struggle at it, then you will retain it, even decades later. This process of learning the next song becomes easier as you do it more, and you will retain that information much better.

I think programming (or any learning), works the same way, Unless you really flounder and discover stuff, you aren't going to retain anything, and you'll always have to seek out answers to basic things. Struggle, rinse, repeat, until the basics become second nature. Struggle, rinse, repeat, until the second tier becomes easy, etc etc etc. This way, seeing problems at tier 3 and 4 becomes easier to understand.

At levels beyond simple, you will find a ton of misinformed and downright wrong advice. If you are always looking up an answer without making an honest attempt at figuring out the logic yourself, then you will find yourself trapped in a world of not knowing why something works the way it does. At some point, you'll get bit bad, and at some point, you will not find any correct or sensible answers at all. If you never trained yourself to figure stuff out yourself, especially with the easy stuff, what is your out when things get hairy?

lol @ this life. Spending half of my Sunday writing freaking React unit tests for an upcoming interview's "we'll just need you to make this sample app" thing. Second one I've done, first I did it in about 3 hours, and I got all sorts of "why didn't you do x, y, z" which would have doubled the time questions, didn't get the job, so now I'm making this one freaking perfect so I don't get that any more. Also I told the recruiter a huge number that I didn't think they could do and she hesitated and said she'll fight to get me there so I guess this is my life now. The more I work at different places the more I figure out that web programming is all exactly the same and all that matters is that you don't work in a total garbage place and that you make as much as you can.

Yeah I spent 7 hours on the Netflix take home thing and basically got "Why didn't you create your own shadow DOM?".

And I even specifically called out that I was using the DOM to keep track of state as a shortcut around writing a full blown two-way-binding framework. Which is exactly how I would develop the app - get it working, then abstract out one piece at a time as it becomes obviously necessary. I refuse to add in extra layers of complication if I don't fully understand the problem.

I never claimed to them I was an expert in DOM manipulation or a front-end guru. Just that I had a lot of experience with the front-end, Javascript, and node in particular.

I don't think any of my notes in the email, or the fact that I was being considered as someone who knew a ton of JS but not currently up on all front-end stuff, made it to the person who reviewed the app. Next time I will put them right in the code.

// I AM NOT A FRONT-END GURU - THIS IS KNOWN TO (guy who contacted me)

lol

The instructions as well were super vague - basically create this SPA w/o using anything heavier than jQuery. What they wanted was for me to take a stab at my own high-level JS framework. Imagine if I spent like weeks on that, still didn't get the job, then a year later my framework is the kernel for Netflux™ - a lightweight modern unopinionated JS library.

This one is a bit simpler and was basically "use react" but a) they require you to serve the file (and their provided JSON) with Node, I'm decent at Express but still had to build a whole backend and api endpoint so it could make the ajax call, no way the average front end guy could do that, and b) its just a ton of work. Basically make a whole product page in the amazon style to buy a product online. I wound up with 13 components including a carousel, reviews, incrementer, etc. 53 jest/enzyme unit tests and could do at least 20 more.

I exceeded every requirement so if they're not blown away I'm going to be disappointed. At the very least I have this thing I can hollow out for boilerplate if I need to start a new project or something... and always "wanted" to get better at unit tests so there's that..

well, I dont think you should just rote copy the first answer. and while I dont remember exactly how to do everything, I do remember where or when I did something or something similar and go grab it and alter it.

I have some languages where I do the find something similar thing. But I think it's definitely a sign that you don't know the language very well (in some relative sense).

A simple example:

If you are having some problems with learning how if-statements works, you would want to really take the time to figure that out without looking up the solution right away. You may also try using "else if" or see what happens when you remove "else" entirely. You eventually want this to be natural, and it's perfectly okay to struggle a bit to ingrain it.

If you haven't mastered the syntax and concept of if/else, you are bound to struggle with JavaScript promises (this is what Larry Legend was talking about).

https://developer.mozilla.org/en-US/...bjects/Promise

If promises are something I'd expect to use semi-regularly, I'd take the time to really learn the syntax and idea cold. I'd think that more complex solutions will likely have a very high signal / noise ratio, or, at the least, lower relevance to what I'm working on. I may as well take the pain upfront.

(not a JS developer, so it's possible everyone has mastered promises and it's hunky dory to copy / paste with abandon)

Stackoverflow is amazing obviously but i would recommend looking at documentation (that they hopefully link to)... then you figure out what method you needed but also can quickly see a bunch of other methods and get a better understanding of how it works.

How often do you guys deal with serious data integrity issues?

I was responsible for data loads from our customers at my last place for about 5 years and don't remember more than a handful of missing data from the SFTP servers we used and no problems with data getting munged during transmission.

Sometimes?

It's a bit hard to know what exactly you're talking about here.

Example...

As a result of deleting one resource, there are a number of rows in one table that should have been deleted as well. They are essentially 'orphaned' data (or what I'm calling invalid data) and cause a query that would otherwise work to fail. Accounting for that adds extra, unnecessary complexity to the code base. This is not the first time this sort of thing has happened.

That's pretty rare for us. We've been doing soft deletes almost everywhere for a few years. There's still some bad data from the very early says of the company before we added soft delete but it doesn't cause issues because queries are date constrained to after that period and we've cleaned up the bad data as we find it either through deletes or associating it with dummy data

At some point the pain from it happening will make the changes to the code base acceptable, or someone will write a tool that can quickly and safely clean up the orphaned data.

This isn't an issue of not being able to figure out those orphaned rows. It's an issue of not being able to convince the ppl who are authorized to make db modifications to delete it.

Agreed. Sounds like the process to delete data is broken and the query isn't robust to that type of failure -- might as well fix both as well as clean up production.

Edit: Well, I guess the real problem is that not everyone agrees with your summary of the situation; probably need to fix that first.

Not making those modifications is foolish.

In other news I ran into issues with the rails backend for the project I'm working on and it seems like many people who "know" rails actually don't. I don't know exactly how to search for the issue I'm having and I'm bouncing between 404, 500, and 422 errors all day, fun.

Every system I've ever seen that doesn't enforce data relationships at the database level (like with foreign references in SQL) eventually has orphaned data. Way better to fix the data than to make the code more resilient to missing data, imo.

For sure fix the data, but if orphaned data causes production problems, and if we agree that it is inevitable if the database doesn't enforce it, then I would say you need more resilient queries as well.