|
Bruegels Fuckbooks posted:for some strange reason developers and software test people have some sort of tortured affection for logical positivism. one of my big interests undergrad was epistemology, and working in software, Iroutinely come across ideas about how we know what we know that were shown to be bupkis 400 years ago. Gross overgeneralization--but it explains a ton of the weird ideas I encounter. To be clear I don't think it's that big of a deal, because I long ago learned to put away the philosopher hat.
|
#
?
Jan 22, 2018 15:18
|
|
|
|
| # ? May 13, 2024 00:13 |
|
|
vonnegutt posted:Those are both great ways to get up to speed with a project. I will add one more: Let me add another: try to ask as few questions as possible. Although there is inevitably some background knowledge necessary to do work on a codebase without loving something up, asking questions and digging into things takes time, focus, and effort away from more senior engineers that have to get poo poo done. Asking too many questions can get you a reputation for being unable to figure things out on your own. An engineer who is open to questions and can properly manage knowledge transfer is worth their weight in gold, though. Keep in mind that this is based on my own experience, so it may be different for you.
|
|
#
?
Jan 22, 2018 15:30
|
|
|
Pollyanna posted:Let me add another: try to ask as few questions as possible. Although there is inevitably some background knowledge necessary to do work on a codebase without loving something up, asking questions and digging into things takes time, focus, and effort away from more senior engineers that have to get poo poo done. I'd rephrase that as "try to answer the question yourself first, and mention how you did that when asking it". This way you stand to learn something, even accidentally, and the person answering the question sees you made an effort and may be able to build directly on your demonstrated knowledge rather than answering with the assumption that you don't even know how to get started.
|
|
#
?
Jan 22, 2018 15:40
|
|
|
Today I fired my client, he was shocked to learn that people don't want to work on a project with at least 6 months of technical debt without ever the opportunity to catch up. After that I explained XML and namespaces to someone who claimed to have 10 years of experience in SOAP/XML testing. No clue was had and during the day I kept getting chats for very, very bad XPath expressions with the request as to figure out why it did not work. so  for me I guess.And then a contact called me if I was interested in a contract that would be a 15 minute bike ride for the same rate I get now.
|
|
#
?
Jan 22, 2018 16:30
|
|
|
As a contractor from time to time, I dont mind if theres technical debt as long as I get paid hourly and the client is aware that the technical debt severely impacts my ability to deliver and the solution quality / longevity and maintainability will also be minimal. That way I basically absolve myself of blame mostly for pushing out crappy code that I spend way too long on (because I was getting past bugs in my dependencies for 70% of my cycles, not working on new code itself). Its extremely profitable (well, for services at least) to do this even at scale and combined with asking for more money to add features closer to delivery, you should do fine even if you dont get repeat clients so much because a lot of the companies that treat their work this way will not be in business another few more years. Who wants repeat businesses with dying companies besides private equity firms anyway?
|
|
#
?
Jan 22, 2018 16:45
|
|
|
Pollyanna posted:Let me add another: try to ask as few questions as possible. Although there is inevitably some background knowledge necessary to do work on a codebase without loving something up, asking questions and digging into things takes time, focus, and effort away from more senior engineers that have to get poo poo done. Asking too many questions can get you a reputation for being unable to figure things out on your own. An engineer who is open to questions and can properly manage knowledge transfer is worth their weight in gold, though. If you're the new guy please don't do this. Don't follow any of this advice. Not asking questions early on will inevitably cause extra work for senior developers down the line. If you aren't sure about a specification or requirement, just get up and ask someone. Especially within the first 24 hours of contact with a new project. Ask as many questions as possible until you feel comfortable. Obviously there is some discernment here. If the problem is "How do I pass by reference in C#" or something then yeah do some googling for 20-30 minutes and try and figure it out yourself.
|
|
#
?
Jan 22, 2018 18:04
|
|
|
Jesus tapdancing christ do not be afraid of asking too many questions, especially if it's about something specific to the products. What the gently caress. Edit: Also agreeing with Portland that if it's a language question, a quick google/stackoverflow can (and should) answer it for you but there is SO MUCH poo poo that is going to be specific to your company and your team's workflow that SO isn't going to be able to help you with. Here's a guideline: If you google something and can't find a solid answer within 5 minutes, go ask someone. Do not spin your wheels for fear of looking like you don't know what you're doing. If I may speak for engineers as a whole, we hate people who try and bullshit their way through their jobs (because the rest of us have to pick up their slack), and we much prefer that someone who doesn't know something admit it, so we can teach them and build them up, and by extension make the entire team more effective. Speaking for myself, I like teaching newer people because it helps solidify (and sometimes correct) my understanding of the products we're working on and the technologies we're using. If someone is too busy to help you they will tell you, but still probably point you in the direction of an answer or to someone who can. Che Delilas fucked around with this message at 18:21 on Jan 22, 2018 |
|
#
?
Jan 22, 2018 18:14
|
|
|
ITT Pollyanna learns the wrong lessons from bad job experiences.
|
|
#
?
Jan 22, 2018 18:15
|
|
|
Asking too many questions may waste 30 minutes of someones time. Oh well. Not asking enough questions may waste months of everyone's time. If you work somewhere where you are discouraged from or intimidated into not asking questions find a new place to work.
|
|
#
?
Jan 22, 2018 18:17
|
|
|
Pollyanna posted:Let me add another: try to ask as few questions as possible. Although there is inevitably some background knowledge necessary to do work on a codebase without loving something up, asking questions and digging into things takes time, focus, and effort away from more senior engineers that have to get poo poo done. Asking too many questions can get you a reputation for being unable to figure things out on your own. An engineer who is open to questions and can properly manage knowledge transfer is worth their weight in gold, though. What the gently caress is this poo poo? If you aren't asking questions and you are new, I would be really really loving scared and suspicious of you. Engineers SHOULD be asking questions. ALL. THE. TIME. Even senior engineers. What on earth possessed you to spew out this terribad drivel and call it "advice"?
|
|
#
?
Jan 22, 2018 18:32
|
|
|
I think we're finally getting to the root of Pollyanna's workplace problems.
|
|
#
?
Jan 22, 2018 18:46
|
|
|
ratbert90 posted:What the gently caress is this poo poo? If you aren't asking questions and you are new, I would be really really loving scared and suspicious of you. The important skill to learn is "how to ask good questions". I have clients who ask me, "Any idea why this didn't work?" and link me to something with a stack trace that explains the exact problem. It makes me think they're incompetent and not capable of reading logs and reasoning about error messages. If they did the same thing and said "the stack trace says foo, I tried bar and baz but neither worked. Any ideas?" I'd have a lot more respect for them. The former just says, "I'm too lazy/incompetent to even attempt to troubleshoot on my own." The latter says, "I understand the problem and have attempted to solve it myself, but I'm stuck", which is normal and fine. In general, a question should follow Stack Overflow rules. The essential parts are: 1) What you're attempting to do 2) What the exact problem is (not the statement 'it didn't work') 3) What you've tried 4) What didn't work with what you tried It's the difference between, "help, this doesn't work" *copy and paste of code with no context* and "I'm attempting to pass a Foo into Bar, but it throws a null reference exception. I've checked if Foo is initialized first and it looks okay, any thoughts?" The former is going to result in someone having to play 20 questions with you. The latter is going to give them the information they need to fire off a few quick suggestions or give you a correct answer. Hell, the act of writing down the question in the first place might give you an "ah-hah!" moment that answers your own question.
|
|
#
?
Jan 22, 2018 19:05
|
|
|
New Yorp New Yorp posted:The important skill to learn is "how to ask good questions". In my experience Stack Overflow seems to put about the same value in question asking as Polyanna does. IE. Just don't do it.
|
|
#
?
Jan 22, 2018 19:16
|
|
|
Okay, then I take it back. Do ask as many questions as possible (within reason as New Yorp explained), because taking some time to hash things out before code gets committed is a lot better than running into problems later down the road that are now magnified x 100. That's what I actually believe.
|
|
#
?
Jan 22, 2018 20:42
|
|
|
I got through my first day. It was nice. Very little of it involved anything I'm going to be doing. I did manage to install VSCode, as well as Node and Git.. That's about it. Other than that my day was spent chasing people around for passwords and ID cards and the usual stuff. Everyone was pretty nice, and the laptop I was given is like a little demon in a box. It's all gonna be ok.
|
|
#
?
Jan 22, 2018 20:50
|
|
|
New Yorp New Yorp posted:In general, a question should follow Stack Overflow rules. Very much this. The process of getting a minimal example for SO question usually ends up with me figuring things out, to the point where I post only about 1 question out of 10.
|
|
#
?
Jan 22, 2018 21:36
|
|
|
I fuckin' love it when people ask me questions. Good questions, bad questions, any kind. Ask questions. Make sure "What can I do better?" is one of them, at appropriate times.
|
|
#
?
Jan 22, 2018 22:47
|
|
|
I have someone that wants to explain all the parts of the issue they are dealing with, when I already know all of it and just need to get a yes/no summarization question answered. Don't ask questions that you can google, or figure out through experimentation .e.g. you are being too lazy to work through it DO ask questions that cannot be answered by the above. Just don't be friggen lazy I dunno what to tell you. Think through stuff, don't come to me with half thought through issues, no blabering, no wandering. I'm more than happy to hang out with you some other time, but let me help you become more efficient for your sake and MINE.
|
|
#
?
Jan 22, 2018 23:20
|
|
|
DO: research independently DON'T: refrain from asking questions in order to prove yourself independent or smart
|
|
#
?
Jan 22, 2018 23:32
|
|
|
Have a plan with your questions. Respect the concentration of your teammates, if someone has headphones on and is staring intently at their screen while typing up a storm, see if someone else is checking Facebook. Focus on self help. Ask questions that will help you find answers on your own. "Where is our documentation? Who are the SMEs for the various components? Ask occasional sanity check questions, "Hey, I'm pretty sure that it works like this and this, am I understanding properly?"
|
|
#
?
Jan 23, 2018 00:30
|
|
|
Don't: only get advice from people on internet forums Definitely don't: take advice from someone who only gets advice from people on internet forums
|
|
#
?
Jan 23, 2018 01:22
|
|
|
I think https://jvns.ca/blog/good-questions/ is a pretty good take.
|
|
#
?
Jan 23, 2018 02:43
|
|
|
Don't be afraid of asking questions when you're new. Don't worry about taking up people's time - everyone expects a new hire to have questions. It's a necessary part of getting things right, and everyone knows that's the price of hiring a new employee.
|
|
#
?
Jan 23, 2018 07:12
|
|
|
Minor derail from question-questioning but I suspect some resignations over this one in our department: "... As of this month we are going to be phasing out sugary drinks we provide, and replacing them with sugar free alternatives, with a view that from the beginning of April, we will only have no sugary drinks in the business. ..." One developer is pretty much powered by his 4 can of coke a day habit. Sometimes he switches up and brings his own 3L bottles. And also: Just ask questions, I get asked some pretty dumbass poo poo about stuff senior developers should know and still answer it anyway without passing judgement on the individual. Sometimes you have a brain fart and forget that unless you ToList() an IEnumerable in C# everything is in lazy-fairy-land and can screw up your unit tests, and other times I get asked some really challenging questions which cause me to ask the same question to people smarter than me, which to them might be obvious and dumbass-ey. I think people are overthinking this way too much; I see question asking in IT the same way I imagine a fast food worker sees orders: They don't give a poo poo if you're ordering the quadruple stack, heart attack XL with 4 gallons of Pepsi or just a lean chicken salad, it's just part of the job that passes you by. I certainly don't think less of other developers when they ask questions. I judge them by other things; are they continually breaking production?, or not learning from their mistakes, or being a dick to people. Cancelbot fucked around with this message at 09:29 on Jan 23, 2018 |
|
#
?
Jan 23, 2018 09:26
|
|
|
Cancelbot posted:Sometimes he switches up and brings his own 3L bottles. 
|
|
#
?
Jan 23, 2018 10:46
|
|
|
Stack overflow and irc are inhabited by people burned out through spending all day answering the same questions and so they optimise question policy for them and bite the living gently caress out of newbies for asking wrong. In a workplace the environment is generally quite different, err in the direction of asking that q.
|
|
#
?
Jan 23, 2018 13:19
|
|
|
Honestly when we hire new associate devs we figure itll take 6 months before they are fully productive. Your first or second business environment is way different than anything you learned and thats your free pass time to ask questions and develop your actual business skills. There is a reason your title says jr or associate!
|
|
#
?
Jan 23, 2018 13:32
|
|
|
This is so different from what I've experienced.
|
|
#
?
Jan 23, 2018 14:56
|
|
|
"Hey I think we have a problem, but I'm not really sure. Uhh it could be a problem, but I dunno. Do you know where [the name of a flag that we added to instances] is used besides [some class]" Question that just came to me, while I had headphones on, looking intently at code, in a zone. A question that could be easily found by doing a search all on the code. A search that would take less than 2 seconds and has unambiguous results due to the uniqueness of the flag name. Bad question!
|
|
#
?
Jan 23, 2018 15:18
|
|
|
KoRMaK posted:"Hey I think we have a problem, but I'm not really sure. Uhh it could be a problem, but I dunno. Do you know where [the name of a flag that we added to instances] is used besides [some class]" This is how I deal with those questions in a passive-aggressive way: code:
|
|
#
?
Jan 23, 2018 15:43
|
|
|
Pollyanna posted:This is so different from what I've experienced. Which was the point I was trying to make last week. Your situations are not normal in my experience and should not be used for anything but entertainment purposes.
|
|
#
?
Jan 23, 2018 16:30
|
|
|
KoRMaK posted:"Hey I think we have a problem, but I'm not really sure. Uhh it could be a problem, but I dunno. Do you know where [the name of a flag that we added to instances] is used besides [some class]" And yet if they didnt know the exact name of the flag or a class its used in, suddenly its a good question.
|
|
#
?
Jan 23, 2018 16:32
|
|
|
A lazy question is a bad one. That's about it. Anything else I'd just varying degrees of good and if you're so petulant as to passive aggressively respond to coworkers that ask non-lazy questions you're part of the problem.
|
|
#
?
Jan 23, 2018 18:09
|
|
|
leper khan posted:And yet if they didnt know the exact name of the flag or a class its used in, suddenly its a good question. Yea thats right. They new the name of the flag, and where to find it if they didn't.
|
|
#
?
Jan 23, 2018 18:25
|
|
|
Cancelbot posted:Minor derail from question-questioning but I suspect some resignations over this one in our department: Probably for the best if you work with grown supposed adults who would ragequit a job that stopped stocking their preferred free candy.
|
|
#
?
Jan 23, 2018 18:49
|
|
|
I'd recommend Rubber Duck Debugging when trying to decide whether to ask a question. Take the question you were going to ask, and ask it to a rubber duck, to a picture on a meeting room wall, to your nerf toy, whatever. Talk it out, thoroughly, give all the information you have and what you've tried as if you're talking to a person. If you have not solved your problem half way through, ask an actual person.
|
|
#
?
Jan 23, 2018 19:10
|
|
|
Munkeymon posted:Probably for the best if you work with grown supposed adults who would ragequit a job that stopped stocking their preferred free candy. Oh I agree, only one person complained in the end; and he was once suspended because he was playing Pokemon Go using an emulator on his dev machine. The rest of us are functioning adults.
|
|
#
?
Jan 23, 2018 19:45
|
|
|
Volmarias posted:I'd recommend Rubber Duck Debugging when trying to decide whether to ask a question. Take the question you were going to ask, and ask it to a rubber duck, to a picture on a meeting room wall, to your nerf toy, whatever. Talk it out, thoroughly, give all the information you have and what you've tried as if you're talking to a person. This is one of the reasons Im more productive in an office than an open floor plan. There are others. Currently in open office 
|
|
#
?
Jan 23, 2018 19:50
|
|
|
Don't give coke your money. Theyve hired paramilitary groups to bust uniions in South America, resulting in murders. Each can of coke has a little bit of several lives in it that were trying to unionize so that a corporation couldn't bully them further into poverty. Same with nestle, they see buying up water rights and planning to screw everyone via capitilism at some point.
|
|
#
?
Jan 23, 2018 19:56
|
|
|
|
| # ? May 13, 2024 00:13 |
|
|
theres no ethical agilefall under capitalism
|
|
#
?
Jan 23, 2018 19:58
|
|
