|
smackfu posted:OMG, when agile meets an entrenched DBA group, so painful. I viscerally know that pain 
|
#
¿
Jun 2, 2016 13:58
|
|
|
|
| # ¿ May 12, 2024 15:32 |
|
|
Pollyanna posted:Dramamine makes you extremely sleepy, I've learned. Working in Development:The worst part of computers isn't the computers themselves, but the people using them
|
|
#
¿
Jun 24, 2016 18:18
|
|
|
PT6A posted:How do you get to be a programmer that someone would actually hire without learning something about memory management and the difference between the stack and the heap? Are these the sorts of shits being turned out by "boot camps" and "code dojos"? I feel like there are a lot more self-taught people out there than anyone wants to admit, and the self-taught people I know have some gaping holes in their theory knowledge.
|
|
#
¿
Jun 29, 2016 16:41
|
|
|
I worry a bit because I want to get into jobs that will likely require decent C++ skills and, while I'm better at pointers than most people I went to school with, I still only took two classes that dealt with C. Core classes were all java, fringe classes were all academic languages (let me tell you about Eiffel  ).
|
|
#
¿
Jun 30, 2016 14:27
|
|
|
Volmarias posted:This Book was pretty valuable when I made that leap as well. Awesome, I'll take a look
|
|
#
¿
Jun 30, 2016 14:47
|
|
|
I only discovered the joys of unit testing recently (early in this thread, I think) and I cannot concieve of the kind of mind that thinks "nope those are a waste of time". They've saved me so much time from manually testing, and it's so easy to know when you've broken something if you have halfway decent tests. There's a couple teams working on my current project, and one offsite team is incredibly lax in this regard, and it shows. They've become something of a running joke in the office, because you can be sure that if something's hosed on the main branch, it's because they put it in.
|
|
#
¿
Jul 7, 2016 13:55
|
|
|
Portland Sucks posted:Question to you guys about sick days. Depends on the supervisor. If you have an old-school-work-ethic sort of supervisor ("if I'm not actually dying, I'm coming in to work because that's the right thing to do!") then you probably just have to resign yourself to suffering. If you have a reasonable, normal supervisor, then just talk to them and explain the situation. In most non-retail, non-food-service jobs I've experienced, people tend to be understanding and okay with it if you're not doing too hot, especially if you're in visible distress and aren't just calling in because you have the sniffles. Obviously though, as an intern you're going to be taking the pay hit for those days off. Which, admittedly, will probably help convey to your boss how serious you are about your ailment.
|
|
#
¿
Aug 4, 2016 18:12
|
|
|
Ithaqua posted:Yeah, and that's something to look out for in future jobs as well. If they don't treat you like a professional, you don't want to work there. If I called out sick due to legitimate illness and my boss gave me poo poo about it, I would immediately start looking for a job where I was given respect and treated like an adult. My dad has the super oldschool work ethic and every job I had up until about 3 years ago was hourly retail or food service so I still feel guilty every time I call in. My tech lead is hilariously, incredibly cool about everything, and it still weirds me out that I can just send him a message on slack to let him know I'm not coming in and leave it at that.
|
|
#
¿
Aug 4, 2016 19:24
|
|
|
Bragpost: by the end of today, I will have completed 7 story points (which are estimated at about 1 story point per dev day) in the space of two afternoons. I wonder if my tech lead will be okay with me taking a couple vacation days for an impromptu long weekend.
|
|
#
¿
Aug 16, 2016 15:28
|
|
|
Ithaqua posted:The team's estimates being bad is not a cause for celebration. Make sure you bring it up during the retrospective. Yeah we tend to estimate worst-case, plus we're still honing down from what we used to have, which was fairly ludicrous. It's been better since we've started on a lowest-bidder story point system rather than consensus-based
|
|
#
¿
Aug 16, 2016 16:44
|
|
|
Our current system works like so: Read the story. Discuss assumptions, elicit further information from BAs as necessary. Ensure everyone has enough info to estimate. Everyone provides a point count, somewhere between 0.5 and 3 (higher means it should almost certainly be more than one story). The person who put up the lowest number of points gets assigned the story next sprint (this is the key), valued at the number of points as the next-highest estimate,so if I estimate 0.5 and my coworker estimates 1, I get it at 1. For ties, one of us gets it at 1, determined by whoever has the least number of points, or if that's equal then whoever hasn't recieved a story in the longest amount of time. Previously, it was typical planning poker. Same discussion part as above, but after everyone provided a point count we had to come to a consensus on point costs, including discussion with severe outliers, then stories are assigned after everything is estimated. We were having issues with really inflated point costs due to a bunch of reasons, and our new approach has curtailed that somewhat. Ithaqua posted:Lowest estimate is an awful idea. A better solution is to identify what causes your estimates to be so wildly out of line with reality and solve that problem. Getting 7 "days" worth of work done in a few hours means that your estimates are worse than inaccurate, they're totally useless as a metric for planning. 1) Our devs work at vastly different speeds, and for some these estimates are accurate. Plus, people tend to pad out their stories a little because we occasionally have problems interfacing with other teams/the DBA/etc. 2) We are explicitly encourage to estimate with the expectation that one point = one day of development, plus some QA time, plus some BA time. I'm not saying it's the optimal approach, but it's the best we've managed for our team since I started on this project. Let me tell you about the sprint (7 business days) in which I completed 29.5 story points with the same assumed 1 point = 1 day comparison. I did work full tilt for the duration of that sprint, but drat if it wasn't a silly bunch of estimates.
|
|
#
¿
Aug 16, 2016 18:16
|
|
|
Ithaqua posted:Stories also shouldn't be assigned, but should be grabbed by whoever is available in order of priority within the sprint, but that's another story entirely.  I'll talk to my tech lead about it, because your points are all pretty pertinent and would probably ameliorate some of the friction that estimation creates among the team. I think a bigger problem is that the "1 point = 1 dev day" is coming down from on high as well a bit. I don't foresee anything changing (this is for fintech, after all, so we're only working with a close approximation of agile at the best of times), but at least I'll feel better about myself.
|
|
#
¿
Aug 16, 2016 19:28
|
|
|
Yeah given that my previous experience with "Agile" was at a bank, where "Agile" meant "you get a half hour long meeting every morning along with all the other meetings", this is practically nirvana. I look forward to the mythical future when I finally get my rear end out of fintech and maybe get to experience something even better 
|
|
#
¿
Aug 16, 2016 20:00
|
|
|
Xarn posted:Sup buddy, I worked in medtech. 
|
|
#
¿
Aug 16, 2016 20:15
|
|
|
necrobobsledder posted:If you have a Gantt chart, you're probably doing Waterfall probably, not Agile nor agile / lean. Hence, topic title is appropriate. My previous job was the inspiration for the thread title. Someone actually talked about how we were doing it, as if it was a desirable thing. At the very least, I've not had any other Agile experience, so I don't know how good I could be having it. It's nice because I can be pleasantly surprised at every place I go that's better.
|
|
#
¿
Aug 16, 2016 20:37
|
|
|
I just solved the weirdest problem I've yet encountered in my java development experience. I wrote a java method that uses reflection to generate notifications based on object fields that contain a value. I've been waiting on some stuff from another team, so it sat on a backburner for a bit and I never pushed my branch. Other team's code got merged into our branch last night, so I get back into the thick of it today. I get everything to a point where tests are green and push to origin. Notification comes in from Bamboo: build failure. Test failure. One of the tests I just made is failing. Double check my last results - green across the board. I run a local gradle build to see what's up. Build failure, test failure in that same test. It's an assertion failure, of all things - verify(class, times(2)).method(isA(TheGenericClassIOnlyExpectTwice.class)) is being invoked 3 times. All the rest of the assertions are passing, so somewhere I've managed to populate another field. I know my test data is set up correctly. I change my gradle plugin to the new one I hadn't picked up yet, refresh all my dependencies, clean the project, yada yada yada. Still borked. What the heck gradle. I add in a debug println, figure out how to display stdout and stderr in the gradle console output, then run the build again. And there it is - the four fields I was expecting, including two that only flag the generic field, then something called $jacocoData. Turns out jacoco is a code coverage reporting plugin we have attached to our gradle build. In the process of doing it's coverage-reporting thing, it injects a static synthetic field into the class, which getClass().getDeclaredFields() dutifully picks up and reports as having a non-null value. Prior to today I didn't even know that you could inject fields into a class at runtime, much less that that was called a synthetic field. Happily, the Field class includes an isSynthetic() method, and thus my way-too-involved debugging trip ended with 20 characters and now my build is green and I am slowly becoming the team's go-to reflections guy. tl;dr Java reflection is scary
|
|
#
¿
Aug 18, 2016 19:05
|
|
|
|
|
#
¿
Aug 18, 2016 23:54
|
|
|
Steve French posted:Stop. Step away from the computer. Funny, this is basically what my tech lead says to me every time I use reflection  (okay it's not that bad but he is of the opinion that reflection is best used in extreme moderation and flinches every time I mention how easy it was to solve a particular problem with it)
|
|
#
¿
Aug 19, 2016 13:55
|
|
|
Yeah, we designed ourselves into a corner a little bit in this case, but the end result isn't half bad and it's much more flexible than a number of other solutions we looked into.
|
|
#
¿
Aug 19, 2016 15:08
|
|
|
For my capstone project in university, my prof had me go through the entire software development process (requirements, design, development, testing) in an incredibly basic elevator simulation using a process called Jackson System Development. One of the key ideas that the guy who made up the process expounded was that if you're being clever, you are almost always doing something wrong or compensating for bad design.
|
|
#
¿
Aug 19, 2016 19:40
|
|
|
Ever since the day automated testing "clicked" for me, I don't see how it's possible to write a reasonably sized application without proper testing. It's so much simpler than having to manually test everything, and you can be so much more confident in your code when you have a suite of tests that make sure that it runs at least approximately correct. Plus, just the act of testing helps me critically examine my work and find little bits that I missed while developing. It also makes refactoring orders of magnitude easier
|
|
#
¿
Aug 23, 2016 14:04
|
|
|
The Leck posted:Yeah, I've run across this. In a single class.
|
|
#
¿
Aug 26, 2016 13:29
|
|
|
Today I learned what it looks like when a git merge commits messy suicide. Actually it was more like a branch was just sorta drawn and quartered over a series of 10-15 commits and merges. I have no idea what the gently caress happened and my brain feels like a fully extracted tube of toothpaste after trying to decipher the whole goddamn mess. It's like our universe combined with an alternate universe where all my work on a particular API never happened.
|
|
#
¿
Sep 6, 2016 17:35
|
|
|
Hughlander posted:Sometimes you just gotta know when to apply: Luckily, I have a tech lead for that. For the rest of us, it was "git checkout <branch before it died>-temporary" which admittedly still took half the day to get working properly 
|
|
#
¿
Sep 6, 2016 20:32
|
|
|
Do any of you use linter information for code cleanup at work, and if so how helpful do you tend to find it? I spent the majority of today working on paying down tech debt as reported by Sonar and I got to wondering how much of this was stuff people actually worry about overmuch. I imagine it's at least partly domain-dependent - I'm working in java, so a lot of stuff I fixed was along the lines of "use isEmpty() rather than size > 0" or "use the diamond operator rather than redundantly respecifying generic parameters". However, stuff like reducing cyclomatic complexity seemed like it would be more widely applicable.
|
|
#
¿
Oct 17, 2016 21:17
|
|
|
Okay that's sorta what I expected. I've gone through this stuff a couple of times and I will admit it's definitely instilled some better habits and helped me become more familiar with some of the java features I didn't know much about. Plus, figuring out how to deal with the cyclomatic complexity and overnested ifs/fors/etc has helped me stretch my brain a bit, which is nice because it's not like anything else is going to do that in banking
|
|
#
¿
Oct 18, 2016 13:32
|
|
|
Yeah, pretty much. My tech lead described it best: "honestly, all we're doing is taking this and putting it over here." Middletier server software is not very complicated - take input from frontend, translate it from view object to model object, put model objects in the database. Mostly, my satisfaction comes when I get to learn a new java feature that I haven't touched before (the first function I wrote after learning about Optionals, Streams and Lambdas was an unholy mess), or when I get to write something clever or elegant to replace big gross walls of spaghetti code. I also get cathartic pleasure from ripping out core functionality and getting the bleeding remnants patched back into something functional again. I feel like one of those guys that mugs you and steals your kidney and leaves you in an ice-filled bathtub.
|
|
#
¿
Oct 18, 2016 14:00
|
|
|
More linter victories: I figured out how the :: operator works in java  Also one of the guys on my team checked out my code review and helpfully came over to teach me how the Stream.map() function works, helping me reduce 8 lines of janky code to 4 lines of halfway decent looking code. Feeling good today 
|
|
#
¿
Oct 18, 2016 15:51
|
|
|
git is actual real magic
|
|
#
¿
Nov 1, 2016 16:12
|
|
|
oh god I shouldn't be allowed to touch code I've been frazzled this week because I've been juggling about a billion tiny stories that have had wierd qa problems, integration support, and regular stories. It all came to a head today when I opened up a PR that contained the following snippet code:
|
|
#
¿
Nov 1, 2016 17:49
|
|
|
I mean really all I did was revert a merge that happened last week, I was just amazed that it worked so well. I first learned git for a university course and we weren't "taught" so much as "told to use git and shown how to push/pull". This being a second year university course, our code was all jammed into one file. None of us knew how to merge. We ended up just using dropbox (because why bother even getting a notification when you're about to completely overwrite someone else's code ) Now, every time I attempt something outside the realm of my understanding, I generally expect that I'm going to irrevocably destroy everything and have to start from scratch. This is not ameliorated by the fact that my first real dev job was at a bank that used SVN, and so sometimes just pulling would break everything to the point that I'd just wipe everything and start from scratch.
|
|
#
¿
Nov 2, 2016 12:20
|
|
|
today in Learning Git With ChickenWing: git rebase --onto I'm worried that one day this all might make sense and I'll never be able to use another SCM again. Reading that "git is a graph" guide is rapidly accelerating me in that direction
|
|
#
¿
Nov 7, 2016 21:18
|
|
|
Che Delilas posted:Just bitching a bit. The solution is to go out for beers with your team afterwards and all laugh at how he expects you to feel guilty for not working 60 hour weeks like a permacrunch shop
|
|
#
¿
Nov 10, 2016 13:20
|
|
|
|
|
#
¿
Jan 4, 2017 21:46
|
|
|
I swear to god the longer SIT goes the more I come to understand why people hate null.
|
|
#
¿
Jan 5, 2017 18:40
|
|
|
ill say what i loving want 
|
|
#
¿
Jan 12, 2017 14:31
|
|
|
Messyass posted:So I'm reading through this RFP... Oh neat are you us a year ago? "Make us this thing. Here's a bunch of use cases. What's a requirement?" Look forward to: hilarious scope creep, hilarious deadline expectations, not hilariously having to manage the aforementioned. I mean, we're making it happen, and we're making truckloads of money from it, but god drat has the process been miserable.
|
|
#
¿
Jan 19, 2017 17:24
|
|
|
Oh, the joys of neo-socialism ( ) and the banking industry(Unlimited vacation, unlimited sick days )
|
|
#
¿
Jan 27, 2017 19:59
|
|
|
Gildiss posted:Working in Development: We must honor the ceremonies of Ag'Ile
|
|
#
¿
Feb 2, 2017 17:21
|
|
|
|
| # ¿ May 12, 2024 15:32 |
|
|
Technically I'm a consultant not a developer by title so I'm going to have to do full-time BA/QA at some point and let me tell you how much I goddamn dread the day. I mean, it'll be good for me and make me into a more well rounded and empathetic dev but it's gonna hurt in the process.
|
|
#
¿
Feb 3, 2017 14:28
|
|