4 ms·

Full stack developers who have been working for decades have also been doing sql for decades, because most substantial software uses a database. Perhaps the DB

Full stack developers who have been working for decades have also been doing sql for decades, because most substantial software uses a database. Perhaps the DB server has changed (I’ve gone deep on Postgres, MsSQL, and MySQL) but the principles are largely the same and while there is plenty vendor-specific knowhow, that is just stuff to learn. > because I had a ton of other language experience behind me Yes, a full stack dev needs this. Why wouldn’t they have it? You seem to be conflating seniority/experience with breadth of skill. Edit: I'll also point out that languages aren't the only thing that "rhyme" in tech. If I were already experienced with Pulsar and Rabbit, I'm not going to have much trouble with Kafka. If I know Terraform well, CloudFormation isn't going to be a complicated new tool. Etc. Having breadth of experience makes taking on seemingly complicated new things far less daunting, as you point out with your c# example. That applies across the board. > How about web dev? I’m not quite sure what you’re trying to say here, but web dev is pretty straightforward, and of course full stack devs have typically done a lot of it. You are either overestimating how hard it is to learn all this stuff, or you are underestimating how close you are to being able to do it yourself. Edit. Here is a framework for thinking about it. You have been doing SQL for decades. But how much genuinely new skills related to SQL have you learned in the last, say, 5 years? Probably not many, because learning is logarithmic like that: you learn quickly at the beginning, and then more and more slowly. So what if you had instead learned a new skill 5 years ago? You'd be quite good at it by now. And if you kept using SQL, you'd stay pretty good at that too. Rinse and repeat a couple times and you're a full stack dev. You'd notice another advantage too: the undercurrent of convergence, where you notice the same patterns emerging in disparate parts of the stack and architecture, and finding yourself reapplying the same principles in very different contexts.

zasdffaa 4y ago
Please see my other answer as well https://news.ycombinator.com/item?id=31810593 https://news.ycombinator.com/item?id=31810593 Quick question. This. with tbl as ( select x from ( values (10), (20), (30) )as tt(x) ) select \* from tbl where x not in (10, 30) this gets you x --- 20 as the result without running this (same query as above but for addition of a null): with tbl as ( select x from ( values (10), (20), (30) )as tt(x) ) select \* from tbl where x not in (10, 30, null) what's the result? This can be an expensive mistake. It threw my old company into a flurry. Rare, but it happens - do you know why? > while there is plenty vendor-specific knowhow, that is just stuff to learn that stuff is precisely the difference between sleeping at night and "WTF now???, it's 3am and the clients are phoning me from singapore". And then losing your company or spending 20X unnecessarily on a scaling up box. You underestimate it. > You are either overestimating how hard it is to learn all this stuff, or you are underestimating how close you are to being able to do it yourself. Yeah, this discussion has been a major eye opener for me. I wish it had come much earlier. Thanks.
- icambron 4y ago
  I know how `NOT IN (null)` works just fine. Now what? Remember that full stack devs have also been writing SQL for their whole careers. It's weird that you have somehow confused "I have specifically avoided these parts of the stack" with "LOL you guys must not know SQL". Just a bizarre thing to say.
  - zasdffaa 4y ago
    My point was if you don't know something well, you fall into expensive traps. This was one that hit our company - some sql devs don't even know sql has ternary logic and why that matters. Another that hit our company, was not understanding isolation levels in SQL, meaning that two people who could write SQL very well didn't realise their approach to avoiding a race condition just didn't work. When I pointed that out, they had a hotfix on client sites by the end of that afternoon. I worked on the Cassandra database, we were having problems (albeit in development, it didn't reach production). Turns out truncating in the database did not release the space. That was causing people a lot of problems in till I ran into that by chance. These were full-stack, and smart, I respected them. You can't have what I consider thorough knowledge on all fronts, and if you don't you can pay very heavily (I can give other examples). No more than that, no LOL'ing at people. Draw your own conclusions I guess. Anyway, thank you for taking the time to reply and for several people here pointing out that I've got the wrong end of the stick. Edit: the sql example was me trying to make a point, not trying to catch you out. Please don't take it that way. It came across badly.

zasdffaa 4y ago

Please see my other answer as well https://news.ycombinator.com/item?id=31810593 https://news.ycombinator.com/item?id=31810593 Quick question. This. with tbl as ( select x from ( values (10), (20), (30) )as tt(x) ) select \* from tbl where x not in (10, 30) this gets you x --- 20 as the result without running this (same query as above but for addition of a null): with tbl as ( select x from ( values (10), (20), (30) )as tt(x) ) select \* from tbl where x not in (10, 30, null) what's the result? This can be an expensive mistake. It threw my old company into a flurry. Rare, but it happens - do you know why? > while there is plenty vendor-specific knowhow, that is just stuff to learn that stuff is precisely the difference between sleeping at night and "WTF now???, it's 3am and the clients are phoning me from singapore". And then losing your company or spending 20X unnecessarily on a scaling up box. You underestimate it. > You are either overestimating how hard it is to learn all this stuff, or you are underestimating how close you are to being able to do it yourself. Yeah, this discussion has been a major eye opener for me. I wish it had come much earlier. Thanks.

icambron 4y ago
I know how `NOT IN (null)` works just fine. Now what? Remember that full stack devs have also been writing SQL for their whole careers. It's weird that you have somehow confused "I have specifically avoided these parts of the stack" with "LOL you guys must not know SQL". Just a bizarre thing to say.
- zasdffaa 4y ago
  My point was if you don't know something well, you fall into expensive traps. This was one that hit our company - some sql devs don't even know sql has ternary logic and why that matters. Another that hit our company, was not understanding isolation levels in SQL, meaning that two people who could write SQL very well didn't realise their approach to avoiding a race condition just didn't work. When I pointed that out, they had a hotfix on client sites by the end of that afternoon. I worked on the Cassandra database, we were having problems (albeit in development, it didn't reach production). Turns out truncating in the database did not release the space. That was causing people a lot of problems in till I ran into that by chance. These were full-stack, and smart, I respected them. You can't have what I consider thorough knowledge on all fronts, and if you don't you can pay very heavily (I can give other examples). No more than that, no LOL'ing at people. Draw your own conclusions I guess. Anyway, thank you for taking the time to reply and for several people here pointing out that I've got the wrong end of the stick. Edit: the sql example was me trying to make a point, not trying to catch you out. Please don't take it that way. It came across badly.