|
My job is unironically wonderful except that it's way more process heavy than it usually is, despite us wanting to have an agile methodology.
|
#
¿
Nov 25, 2015 17:18
|
|
|
|
| # ¿ Apr 27, 2024 09:32 |
|
|
ChickenWing posted:I acutally was recently upgraded to a 6-core@3.4ghz Xeon machine with 32GB RAM and a 256GB SSD How quaint, you build your code on your desktop.   
|
|
#
¿
Nov 25, 2015 19:11
|
|
|
HardDisk posted:The secretary that handles the punched cards isn't the cloud. Not even if they're heavenly?
|
|
#
¿
Nov 25, 2015 20:05
|
|
|
ChickenWing posted:Oh my god. Welcome, friend. My your coverage be full and your tests meaningful.
|
|
#
¿
Nov 26, 2015 17:23
|
|
|
Asymmetrikon posted:We're finally (maybe) getting version control at my job. Still writing code directly on production servers, but, you know, baby steps.  How in the world do the powers that be rationalize not having version control? I can only assume that means that there's no sort of code review process either.
|
|
#
¿
Nov 28, 2015 01:27
|
|
|
Cancelbot posted:More of a rant; Sometime in April we moved from "product" alignment to "project" alignment, despite the business being very much oriented around products; Call centre app, fulfilment, delivery management, stock, Front end website etc. I've heard the same criticism from the people I talk to at my last job. They've organized around Streams as well, except that they did this by taking teams of people and just chopping them up so that each Stream has one or two people, which means that everyone is stepping on everyone else's toes all day, and no one has a clear idea of what's supposed to even be happening.
|
|
#
¿
Dec 2, 2015 18:58
|
|
|
ratbert90 posted:The gigantic project I am working on had no automated test API's. I finally said gently caress it and started writing them. I cannot imagine the level of fuckery involved in writing unit tests for embedded C stuff.
|
|
#
¿
Dec 9, 2015 15:28
|
|
|
ratbert90 posted:I'm a embedded Linux engineer; so it's not that hard. I mean more the excitingly unpredictable nature of your compiler, etc
|
|
#
¿
Dec 9, 2015 15:35
|
|
|
Find a 20% project, do some codelabs for stuff that seems interesting or relevant, fix technical debt, drink coffee. Mostly coffee.
|
|
#
¿
Dec 11, 2015 16:37
|
|
|
Cicero posted:Officially matched with an intern today! Awesome, enjoy it. Hosting my intern was a great experience. Just remember to budget like 20% of your time for the care and feeding of their work life.
|
|
#
¿
Dec 13, 2015 20:13
|
|
|
ChickenWing posted:At least I'm not worried about not having any work now 
|
|
#
¿
Dec 17, 2015 15:17
|
|
|
Che Delilas posted:I will say that I love the work environment once we get the managers out of the room and the devs can work together to break out the work items into individual tasks. Imagine if they threw a meeting, and nobody came?
|
|
#
¿
Dec 18, 2015 05:17
|
|
|
Che Delilas posted:I can imagine it easily: they would abandon agile and go back to giving us commands and hard deadlines and generally involving us in the decision-making process as little as possible. I'd rather the devs continue to have the opportunity to organize our own work, because so far that part of it has been a really positive experience for us. http://www.quotecounterquote.com/2011/12/suppose-they-gave-war-and-nobody-came.html
|
|
#
¿
Dec 19, 2015 06:57
|
|
|
I'm getting into serverside programming after about 7 straight years of doing Android.
|
|
#
¿
Jan 21, 2016 17:36
|
|
|
ChickenWing posted:That's a bit of a paradigm shift So far, the fact that everything seems just kind of magical, in a bad, nondeterministic way, and there's just a ton of stuff to actually get something to the point of testing anywhere outside if your desktop. Obviously, that can come up with Android too thanks to oem mistakes, but it feels like it's such a high barrier to prototype something. Honestly, I did this briefly before, the better part of a decade ago, and very briefly several years ago to try to support something we were building. It never clicked with me the way Android did. I'm hoping it gets better this time. I have very bad memories of just trying to loving deploy stock Jenkins, no changes, just the loving .war, back at Amazon, and it won't quite be as bad here, but still. HardDisk posted:As someone that loves serverside programming, dealing with Android was always a source of frustration. Thanks.
|
|
#
¿
Jan 22, 2016 16:08
|
|
|
Project planning methodologies are only a tool, they can't fix management foul ups. The best thing you can do is adjust the available time planning for developers that you know will underperform, such as dividing their hours by 4 for the board so that they only get assigned 10 "hours" of work per 40 hours of availability. This way, when they're later with Project Dingle, it doesn't blow your estimates. Similarly, block out 20 hours per week for "dragging the team upwards" for whoever your good developer is, etc. Make sure that code reviews, tests, etc are accounted for in the effort for each story and task.
|
|
#
¿
Jan 25, 2016 15:15
|
|
|
Axiem posted:When I graduated college, Ruby on Rails was still in version 1, and among my fellow students, I'd only heard it once or twice, as a "hey, I heard about this thing, and it's interesting, but not worth using yet" sort of thing. Also, the iPhone wasn't out yet, and mobile was definitely not a thing. Hadoop was not a thing, and I don't remember ever hearing about "big data" in school. We did all of our AJAX calls by hand in my Internet Programming course; at that time, jQuery didn't even exist yet. Neither did node.js. Or Angular. Or whatever the new hotness is. Stack Overflow did not exist. There was no Github (git wasn't even particularly well-known; we used SVN in my one class that mentioned version control). My Software Engineering class focused primarily on waterfall, because agile was "just a fad". We never talked about writing unit tests or anything like that. While true, there are things now that are Known that should be taught, but aren't. Rutgers CS STILL does not teach students about version control! Versioning has been a thing for decades, it'd be great if they accepted that it wasn't a fad.
|
|
#
¿
Feb 1, 2016 16:51
|
|
|
I hope you found the same in the Statistics department 
|
|
#
¿
Feb 1, 2016 19:13
|
|
|
comedyblissoption posted:Working professionals in the industry in general cannot agree on what good software design looks like. "Good" software design is extremely controversial! One thing every good developer can agree on is that they're incompetent and how have they gone this long without anyone figuring this out, I mean did you SEE that module I just wrote? Jesus.
|
|
#
¿
Feb 3, 2016 04:25
|
|
|
csammis posted:Would anyone actually ask this? Real-world read speed and query-to-result is going to be dictated by pressures on the database engine by other queries and memory / tempdb caching, not just table size. TDWTF is littered with examples of terrible developers looking for a row in a table by doing SELECT * and then iterating over the results. Even if the database responded instantaneously, it's still an O(n) vs O(1) operation. As your data sizes get larger and larger, having a grasp on the complexity of your queries and your critical sections can have outsized results.
|
|
#
¿
Feb 3, 2016 15:59
|
|
|
It's a breath of fresh air, in general, especially once you learn all of the editing shortcuts. There's a lot of nice little things, like intelligently autocompleting variable names that you're declaring by guessing what you'd call it. The debugger isn't so good, and the static analysis tools aren't as great as eclipse provides.
|
|
#
¿
Feb 23, 2016 15:24
|
|
|
Like everyone else said, don't feel bad about putting down 4 hours each for the two tasks you completed in the day. Time tracking can be an absolutely great tool to help measure velocity and see how much time is actually being spent in certain areas, but don't take it too literally, and don't forget that without taking breaks your performance will suffer.Illegal Move posted:I'm starting to feel really guilty about this, and I keep thinking that somebody will question me about it and I'll get fired I guarantee that this will not happen because quote:but in reality, my team seems to be really happy with my work. That's the important part. You're being way more productive than you think. Also, Imposter Syndrome is a very real thing in our field. Relax, you're actually that good. Volmarias fucked around with this message at 04:29 on Mar 7, 2016 |
|
#
¿
Mar 7, 2016 04:25
|
|
|
ChickenWing posted:Alright, interview is on thursday - I'm interviewing for a consultant that primarily works with financial systems, what sort of stuff should I be focusing my studying on. I'm a little rusty on my algorithms and I'm guessing a bit of encryption wouldn't go amiss. I haven't started yet because I've been busy studying for exams What's the job? It should have reqs etc.
|
|
#
¿
Apr 6, 2016 03:25
|
|
|
I honestly can't imagine doing it. It seems like an amazing way to make sure that you never get into your flow.
|
|
#
¿
Apr 16, 2016 05:05
|
|
|
Whenever I hear about strict Pair Programming, I think about Bitbucket's Spooning
|
|
#
¿
Apr 18, 2016 04:34
|
|
|
Gounads posted:Touching people is overrated. Only within the workplace 
|
|
#
¿
May 29, 2016 17:15
|
|
|
metztli posted:If your code reviews are at all like meetings, you're doing something terribly wrong. Seriously. Code reviews should be asynchronous, with a direct chat if something cannot be easily agreed upon. Code reviews should happen through a tool dedicated to it if at possible. If you're having Code Review Meetings then something is hosed up. Of course, nothing can solve incompetent coworkers.
|
|
#
¿
Jun 3, 2016 13:43
|
|
|
good jovi posted:Code review meetings are a really good idea once in a while, especially when you're introducing something new or particularly complex. They shouldn't be the norm, though. That's what design documents are for. You should design the thing ahead of time, instead of doing it and saying "ok this is how it's going to work, hope no one is confused or disappointed."
|
|
#
¿
Jun 3, 2016 15:30
|
|
|
Gounads posted:I've also been experimenting with holding a design sign-off with marketing to assure it's correct. Don't bother, the answer is always no, no matter what they say or sign.
|
|
#
¿
Jun 3, 2016 18:38
|
|
|
You could also tell your stakeholders that you don't have anything interesting to demo yet this week, but if they'd like to see the hello world page on your whatever as you begin working to come on by, and that future weeks will be a lot more useful.
|
|
#
¿
Jun 6, 2016 04:39
|
|
|
Khisanth Magus posted:So, it came kind of down to the wire, but we did successfully complete the important projects that were dumped on me and a colleague after our coworker completely dropped the ball on them. So, yay for that. Enjoy never coding again.
|
|
#
¿
Jun 17, 2016 19:16
|
|
|
The best managers kiss down and kick up, because they realize that their people are the ones making them look good. The worst ones do the opposite.
|
|
#
¿
Jun 21, 2016 02:42
|
|
|
ratbert90 posted:The sheer amount of programmers that program in C/C++ that have absolutely no idea how memory works is mind loving boggling to me. Dehumanize yourself and face towards embedded programming
|
|
#
¿
Jun 28, 2016 19:55
|
|
|
ChickenWing posted: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 This Book was pretty valuable when I made that leap as well.
|
|
#
¿
Jun 30, 2016 14:37
|
|
|
CPColin posted:This is what I always try to get at when we interview people: "What was the worst bug you've encountered and how did you go about fixing it?" and "What are some of the first places you look when you encounter code you don't recognize?" Please don't do this. I can guarantee both that I've worked on some gnarly issues that took days to track down, and that I will not remember them if you ask for examples out of the blue, and will simply resort to a deer stare while desperately trying to remember something recent and then give you a super lame example. Find a different way to ask this, possibly something like "you've encountered a really strange bug (details go here), how would you try to solve it?)
|
|
#
¿
Jul 1, 2016 14:06
|
|
|
KoRMaK posted:That sounds like maybe you need to get better at interviewing. The "tell me about a time that X" is a super typical interview question, and is so expected that most people should prepare for it. In my opinion, it's mostly a meaningless question that gives the candidate room to memorize and train a bullshit response. Amazon officially focuses (or did when I was there) on this kind of question, though they also had training for you to really drill down into the answer and make sure that the candidate actually knew what they were talking about, which was great for the people who were good at that line of questioning. Asking the candidate "hey can you write this fizz buzz level question" and then watching them fail to correctly write a for loop has been a better use of my time. Ask me about the cross cutting concerns of interviewing Android developer candidates!
|
|
#
¿
Jul 1, 2016 15:07
|
|
|
rt4 posted:Wanted: Top Tear Developer
|
|
#
¿
Jul 5, 2016 23:03
|
|
|
smackfu posted:What's so hard about SVN and branching for every story? Not as lightweight as git but seems workable. It's totally a thing you can do, it's just that compared to git, it's very heavyweight. If you want to work on multiple branches concurrently on your local machine (e.g. one in major development, two in code review requiring light changes), you have to have multiple copies of the SVN repo, and your development environment needs to point to multiple workspaces. If the compiler is smart enough to do incremental compiles correctly, this means that every single time you create a new branch (which means realistically upwards of several times a day) you're committing to the cost of a full compile. If your development environment is small enough that a full compile only takes a couple of minutes, that's not too bad, but if it's a "go get coffee while you wait" environment, this has a measurable impact on your productivity. Branch level history also tends to not be as easily useful/interesting as git's graphs can be, too. git log --graph --decorate --all (--etc, see http://stackoverflow.com/a/9074343 and the links therein for a few great examples) can be really neat to look at, depending on your environment. Volmarias fucked around with this message at 16:05 on Jul 24, 2016 |
|
#
¿
Jul 24, 2016 16:02
|
|
|
My pod is super roomy and everything, and my team basically just wants you to mention that you're not coming in if you're staying home sick (official company policy is unlimited sick days, within reason). For reference, a former team mate of mine who transferred across the country had their boss pushing them to do deployments while they were immobile at home in bed in a cast. Fortunately, I was able to convince them to change teams, post haste. Bongo Bill posted:If you can't think, you can't work. If you can't work, then your job is to recover. The best and fastest way to recover is to stay home and rest. Similarly, if you being out or being hit by a bus makes that much of a difference to your team's performance, that's not your fault, that's your team's fault for making you a single point of failure.
|
|
#
¿
Aug 6, 2016 04:06
|
|
|
|
| # ¿ Apr 27, 2024 09:32 |
|
|
IAmKale posted:Not to mention the fact that he balked when he saw our CI dashboard showing our build process; there's no CI to speak of with the company's main product and we think a large part of it is the founder's belief that tests "can just be simple python tests you manually run before deployment" 
|
|
#
¿
Aug 17, 2016 05:25
|
|
