|
It's not unusual for a DBA to want to design the tables before you start development. In theory that is part of their job. It's also not unusual for developers to hate this and for the resulting tables to be terrible in some way or another.
|
#
?
Feb 9, 2017 13:55
|
|
|
|
| # ? Apr 19, 2024 00:10 |
|
|
One thing is for the DBA to want a heads-up and to work with him whenever a DB thing has to change, small or big. Another thing is for him to blow up in a public email berating the dev who did the changes like a total douchebag.
|
|
#
?
Feb 9, 2017 14:18
|
|
|
Haha okay. There is a lot of berating devs in email code reviews. I can't fathom why is done that way but whatever. Thanks for the objective perspective - I think I overreacted when I saw it, but I didn't say anything to anyone. Shouldn't be a big deal.
|
|
#
?
Feb 9, 2017 14:35
|
|
|
Doghouse posted:Haha okay. There is a lot of berating devs in email code reviews. I can't fathom why is done that way but whatever. Thanks for the objective perspective - I think I overreacted when I saw it, but I didn't say anything to anyone. Shouldn't be a big deal. That sounds like a toxic place to me, but if you think it's an overreaction then eh.
|
|
#
?
Feb 9, 2017 14:43
|
|
|
Doghouse posted:Haha okay. There is a lot of berating devs in email code reviews. I can't fathom why is done that way but whatever. Thanks for the objective perspective - I think I overreacted when I saw it, but I didn't say anything to anyone. Shouldn't be a big deal. DBA wanting to discuss table design prior to code review (a normal DBA thing) aside, that bolded part is a problem. Reviews shouldn't involve berating.
|
|
#
?
Feb 9, 2017 15:53
|
|
|
I can see why a DBA would want to be involved in code reviews too. It's not just table design, database performance is also a function of writing queries in a performant way. There's a professional way to have that conversation though.
|
|
#
?
Feb 9, 2017 16:23
|
|
|
DBAs are the ultimate fiefdom builders. If you think about it they're a throw back of the 60s batch processing days. They look at all the other operator positions that have gone away and are terrified they're next.
|
|
#
?
Feb 9, 2017 17:30
|
|
|
Hughlander posted:DBAs are the ultimate fiefdom builders. If you think about it they're a throw back of the 60s batch processing days. They look at all the other operator positions that have gone away and are terrified they're next. But also, web developers are the ultimate lovely database schema creators.
|
|
#
?
Feb 9, 2017 17:54
|
|
|
Steve French posted:But also, web developers are the ultimate lovely database schema creators. That's why they simply gave up and wrote their own schema-less databases! What remains to be seen is how the DBAs will strike back...
|
|
#
?
Feb 9, 2017 18:10
|
|
|
Steve French posted:But also, web developers are the ultimate lovely database schema creators. Schema? Schema? We don't need no stinkin' schemas!  *drives a mongo DB database off a cliff*
|
|
#
?
Feb 9, 2017 18:11
|
|
|
Skandranon posted:That's why they simply gave up and wrote their own schema-less databases! What remains to be seen is how the DBAs will strike back... The accumulated CPU time of all their JS trying to replicate ACID and table joins will inflate their AWS bills and all the managers and bean counters will look up and shout, "Save us!"...and the DBAs will look down, and whisper, "lol"
|
|
#
?
Feb 9, 2017 18:16
|
|
|
minato posted:Schema? Schema? We don't need no stinkin' schemas! FTFY
|
|
#
?
Feb 9, 2017 18:31
|
|
|
Munkeymon posted:The accumulated CPU time of all their JS trying to replicate ACID and table joins will inflate their AWS bills and all the managers and bean counters will look up and shout, "Save us!"...and the DBAs will look down, and whisper, "lol"  well done
|
|
#
?
Feb 9, 2017 18:40
|
|
|
HardDiskD posted:That sounds like a toxic place to me, but if you think it's an overreaction then eh. Eh. Yeah. It's not great. People here tend to be better in person than over email, but still.
|
|
#
?
Feb 9, 2017 19:18
|
|
|
Toxic review process can be a circular thing. We had a new developer who opened a PR that was full of stuff likecode:code:
|
|
#
?
Feb 9, 2017 21:14
|
|
|
Mniot posted:Toxic review process can be a circular thing. We had a new developer who opened a PR that was full of stuff like The first person commenting should have just provided a suggested formatting/rewrite in the comments.
|
|
#
?
Feb 9, 2017 21:22
|
|
|
Steve French posted:The first person commenting should have just provided a suggested formatting/rewrite in the comments. Or a link to the clangFormat arguments they like to use...
|
|
#
?
Feb 9, 2017 21:35
|
|
|
The main problem with clang format is that it hides when you've got a whacko that can't follow the coding style around them. It's a big warning sign.
|
|
#
?
Feb 9, 2017 21:44
|
|
|
ROFLburger posted:
 thanks but now I wish I'd have done the whole diary entry instead of rushing out the last part because I was sure someone else was working on the same joke, which was fairly silly.
|
|
#
?
Feb 9, 2017 21:59
|
|
|
Steve French posted:The first person commenting should have just provided a suggested formatting/rewrite in the comments. Probably. I think we all assumed that someone who was coming in with a "senior" title would just know that you should write code in the same style as the rest of the file you're editing (and that if you hate it you should have a "why the project style needs to change" meeting that's not part of adding a new feature). The code review was short, so the developer got grumpy, so the subsequent reviews were more frustrated, so everyone's feelings got hurt.
|
|
#
?
Feb 9, 2017 22:09
|
|
|
Ugh, hostility in code reviews is the worst. I hated it when I would comment on a pull request and the developer either took it personally or just appeared to. Or when I asked for clarification on why something was done a certain way and the developer explained why, right before changing the code to something else.
|
|
#
?
Feb 10, 2017 01:20
|
|
|
Mniot posted:I think we all assumed that someone who was coming in with a "senior" title would just know that you should write code in the same style as the rest of the file you're editing
|
|
#
?
Feb 10, 2017 01:56
|
|
|
CPColin posted:Or when I asked for clarification on why something was done a certain way and the developer explained why, right before changing the code to something else. Huh? Was this as dickish as I'm imagining it?
|
|
#
?
Feb 10, 2017 04:25
|
|
|
Mniot posted:Huh? Was this as dickish as I'm imagining it? It probably would have been fine if the same pull request didn't already have him taking stuff too personally. As it was, it came off as, "Fine, ugh, I'll change it!" when I really was just asking what the code meant. Made me start to worry he'd start taking every pull request comment as me trying to bully him into changing stuff.
|
|
#
?
Feb 10, 2017 17:52
|
|
|
Say I want to work with a specific technology (language, framework, etc.), or with a particular range of technologies. Should I look for jobs specifically about working with those technologies, or is it better to get any job that I qualify for and work on that technology on the side? The problem with the latter approach is that I don't see how to spin that into a job in that technology. On the other hand, I'm at the point in my career where what language I work in and what framework I use is less important than how well managed the project is, amicable co-workers, good management in general, comfortable work setup (e.g. remote vs. nice office etc.), good mentoring/senior engineer support, benefits, and the opportunity to work on something cool. Unfortunately, I don't really know how to find jobs using that kind of criteria, it's always been via recruiters on LinkedIn or searching AngelList or StackOverflow. I know there's networking, of course, but that's still a work in progress for me... Also, that part about what language I work in and what framework I use not mattering is a bit of a lie. I still don't want to do infrastructure work/devops or front-end stuff. That said, I have no idea how to specialize without limiting my options. Any advice on that front?
|
|
#
?
Feb 10, 2017 23:48
|
|
|
How obscure is the tech you want to work with? If it's Rails, then look for Rails jobs. If it's Io, then look for any job.
|
|
#
?
Feb 11, 2017 00:21
|
|
|
Pollyanna posted:Say I want to work with a specific technology (language, framework, etc.), or with a particular range of technologies. Should I look for jobs specifically about working with those technologies, or is it better to get any job that I qualify for and work on that technology on the side? The problem with the latter approach is that I don't see how to spin that into a job in that technology. Yeah, look for jobs in the technology you want to work with. Once you have a 5+ years general experience, it's a lot easier to get a job as a X dev even if you've never professionally worked with X. Your general experience + competence, plus an explicit interest in X will all stand out. Having even just a little bit of hobby experience with it is great. Doesn't even have to be a side project or anything, just spend some time learning X. Also getting a good job is *hard*. Getting any job is 'easy' (not actually easy, just in comparison). You need to be researching and interviewing a lot, and ready to walk away from places that seem ehh. Specializing does mean limiting your options, but I'd be miserable if I had a really good job but had to work with some garbage technology I hated. It's okay to be picky -- it makes getting a job harder, but not being picky just makes getting a job you won't like easier. Not really a worthwhile tradeoff unless you are desperate for a job. lifg posted:How obscure is the tech you want to work with? If it's Rails, then look for Rails jobs. If it's Io, then look for any job. Even if it's crazy obscure, it's worth a try. Find places that use the thing professionally, and stalk the gently caress out of them.
|
|
#
?
Feb 11, 2017 00:22
|
|
|
Anybody with insights into what things are like at Amazon for SDEs? I've been dealing with an (internal) recruiter, and things so far are going well, but I've heard enough horror stories that I'm more than a little wary of actually going for it.
|
|
#
?
Feb 11, 2017 05:50
|
|
|
Some teams are reasonably good, some are nightmarish. Make sure you get the chance to talk to the team you'd be on and probe hand.
|
|
#
?
Feb 11, 2017 07:28
|
|
|
Pollyanna posted:Say I want to work with a specific technology (language, framework, etc.), or with a particular range of technologies. Should I look for jobs specifically about working with those technologies, or is it better to get any job that I qualify for and work on that technology on the side? The problem with the latter approach is that I don't see how to spin that into a job in that technology. Get on meetup.com and find some groups. Go to some talks and hope that they don't suck (my hit rate's been about 50/50) but most importantly: force yourself to talk to at least one person. I wouldn't expect this to have any immediate returns, but it'll start to get you involved in the community and many people at a meetup will be looking to hire someone at their company doing $meetup_thing. I few months ago I wanted to learn a little about Go, so I went to a local meetup. I met a guy there who was hacking on a DB client library. He showed me some of the code he was working on, and I found a bug that we fixed together as a little pull request on the library's GitHub page. I didn't enjoy Go, but if I had that would have been a good step towards getting hired at a Go shop. There are some domain-specialized recruiters and they tend to be better than the usual bunch. I don't know how enthusiastic they are if you don't already have some experience in the field, but I can send you contact info for some Boston-area recruiters who hire for functional-programming jobs if you like. I've mostly gotten solicited for Scala.
|
|
#
?
Feb 11, 2017 16:49
|
|
|
Pollyanna posted:Say I want to work with a specific technology (language, framework, etc.), or with a particular range of technologies. Should I look for jobs specifically about working with those technologies, or is it better to get any job that I qualify for and work on that technology on the side? The problem with the latter approach is that I don't see how to spin that into a job in that technology. If you're senior enough to make technology choices, you can just pick a new technology to use for a project and learn it at work.
|
|
#
?
Feb 11, 2017 16:56
|
|
|
Bruegels Fuckbooks posted:If you're senior enough to make technology choices, you can just pick a new technology to use for a project and learn it at work. Maybe it's just the companies I've worked for (defense and investment management) but this isn't how it works in my experience. At my soon to be former company people have been trying to bring in Node for years and it's about a year away from being usable by anyone other than the "innovation" teams that test out "new" technology without ever going into production
|
|
#
?
Feb 11, 2017 17:03
|
|
|
Pollyanna posted:On the other hand, I'm at the point in my career where what language I work in and what framework I use is less important than how well managed the project is, amicable co-workers, good management in general, comfortable work setup (e.g. remote vs. nice office etc.), good mentoring/senior engineer support, benefits, and the opportunity to work on something cool. It sounds to me like you're at the point of your career where you need to figure out to be useful and valued at whatever company you do wind up at. "Good mentoring/senior engineer support" is code for blaming others for your own inability to get poo poo done and improve yourself while doing it.
|
|
#
?
Feb 11, 2017 20:40
|
|
|
Jose Valasquez posted:"innovation" teams that test out "new" technology
|
|
#
?
Feb 13, 2017 00:34
|
|
|
"Innovation" is tech lingo for research and development near as I can tell. Large tech corporations can afford it. Some of them are better at achieving returns from exploratory investments though
|
|
#
?
Feb 13, 2017 00:45
|
|
|
Bear in mind the original quote:Jose Valasquez posted:At my soon to be former company people have been trying to bring in Node for years and it's about a year away from being usable by anyone other than the "innovation" teams that test out "new" technology without ever going into production In 2017, Node is not a technology that requires a year of R&D to put into production.
|
|
#
?
Feb 13, 2017 00:56
|
|
|
Eh, there's shock and outrage every time it takes large companies a year or more to upgrade to a new JDK. Investigating a full swap of technology stack over a year is pretty quick if you're analyzing how that may impact the productivity of thousands of teams. There's always some scale at which a problem complicates.
|
|
#
?
Feb 13, 2017 01:33
|
|
|
ultrafilter posted:Bear in mind the original quote: To be fair, it is a giant financial company with trillions of dollars under management, not a tech company. There is a ton of infrastructure built around the existing technologies that has to be built out to support a completely different stack and since it isn't a tech company the business has to be convinced that it is worth the huge investment.
|
|
#
?
Feb 13, 2017 02:08
|
|
|
The Laplace Demon posted:Eh, there's shock and outrage every time it takes large companies a year or more to upgrade to a new JDK. Investigating a full swap of technology stack over a year is pretty quick if you're analyzing how that may impact the productivity of thousands of teams. There's always some scale at which a problem complicates. Can you give examples of that? Thousands of teams being impacted by a swap in technology like a new JDK version feels to me like there's a problem inherent in that dependency.
|
|
#
?
Feb 13, 2017 02:21
|
|
|
|
| # ? Apr 19, 2024 00:10 |
|
|
We don't have a DBA and we're all expected to be pretty SQL proficient. Mistakes happen, but it's usually something like forgetting to index a particular column on a table. In 6+ years we've never had anything major happen to our DB outside of that. We have a shared dev database that everyone can connect to and develop off of, so mistakes are usually found rather quickly even before code review and most DB alters are discussed while sprint planning or grooming because we're not fully at "no downtime" release ready yet.csammis posted:Reviews shouldn't involve berating. Exactly. Reviews should be both review and teaching tool. I generally have my boss as well as some junior devs review mine so they are familiar with the code and can ask questions if they're wondering why I did something a certain way. Sometimes it's the junior devs who tell me that something seems overly complicated and I'm like, "poo poo, you're right".  Mniot posted:Toxic review process can be a circular thing. We had a new developer who opened a PR that was full of stuff like I stand corrected. Bruegels Fuckbooks posted:If you're senior enough to make technology choices, you can just pick a new technology to use for a project and learn it at work. This is what I've been doing more and more of over the last 18 months or so and I love it. Biggest example I can think of is I did a presentation on Cassandra, Hadoop, Scala and Spark and how it could be used for our data. Our CTO took that and ran with it using the technology as a backbone for a new product business case. It's basically stayed my search for a different job being able to bring in new technologies and having the support and excitement from DevOps to do new things in AWS.
|
|
#
?
Feb 13, 2017 02:22
|
|
