|
You start with an incoherent monolithic codebase, and isolate each piece. Now you have microservices. Declare victory.
|
#
¿
Dec 19, 2016 17:15
|
|
|
|
| # ¿ Apr 28, 2024 18:58 |
|
|
I kinda enjoy hearing my data scientist coworker occasionally completely flip out over our software update process. "WHY THE gently caress DO I NEED THE loving WINDOWS ADMIN loving PASSWORD TO INSTALL loving MYSQL INSIDE MY OWN loving VMWARE?" Couldn't have said it better myself.
|
|
#
¿
Jan 12, 2017 18:21
|
|
|
Alternately, you can have a fixed scope or fixed date.
|
|
#
¿
Jan 19, 2017 19:16
|
|
|
I've never had an employer who paid for my headphones, but now that I think about it I don't know why not. Right now I have a laptop with two extra monitors, an extra keyboard and mouse, two docking stations, two power bricks, and this fancy jabber-integrated headset package. But all I need is a laptop and headphones, and work only gives me half of that. The first thing fresh devs are told is even, "buy a good pair of headphones."
|
|
#
¿
Jan 25, 2017 22:02
|
|
|
I've found there's layers of agile, and story points are a step past the "obvious benefits" layer. At the basic layer you breakdown work into estimable pieces, develop in small time boxes, checkin daily with the boss, and checkin weekly with the client. I implemented this on my own when one of my projects spun out of control, and it worked great. Everything in this layer makes simple sense, and even teams that "fail" at agile as a whole will often succeed at following this simple pattern. But above that layer there's this leap of faith, and suddenly you're doing "story points" that measures an untethered unit of effort. One that you vote on. (Some people call it a measure of complexity, but not one that can be measured with complexity measuring tools.) And where the simple level of agile has always given me immediate benefits, even on teams that don't initially buy in, story points haven't. It always ends up being "the number that management tracks." So story points are always dropped, finagled, or lied about.
|
|
#
¿
Jan 30, 2017 23:35
|
|
|
So what is the value of estimating points over estimating hours?
|
|
#
¿
Jan 31, 2017 03:32
|
|
|
Destroyenator posted:One reason is to smooth out differences in experience levels. The team as a unit can do X points in a sprint, not every team member is expected to be able to complete each a story in set number of hours. So if you assign story points, does that mean that you don't estimate hours? Do story points eventually become a function of hours?
|
|
#
¿
Jan 31, 2017 17:01
|
|
|
Talk to your manager. They will want to know what's going wrong with the work, the team, and you. They can't fix problems if they don't know there are problems.
|
|
#
¿
Feb 25, 2017 17:50
|
|
|
The Fool posted:I'm in the US, so the joketruth is that neither is true. I've found it's 3-4 weeks plus 8-10 federal holidays for established companies. Anything less than that and they better be making up for it elsewhere.
|
|
#
¿
Mar 9, 2017 03:10
|
|
|
Mniot posted:That only matters for non-exempt employees. It's saying that if your office tells you to stand by in case of emergencies for the next 80 hours, then you are working for those hours (even if nothing happens). If that triggers OT, you get OT. However, if you're an exempt salaried employee (you are) then the fact that DoL considers you to have worked 80 hours doesn't mean anything because you are exempt from OT. There's no maximum amount that your employer can force you to work. I know a radtech who used to be on-call for a hospital. She got paid a small amount per hour just to carry a pager, and a got overtime every time the pager went off, rounded up to one hour increments. Whereas I, as an exempt programmer, carried a pager for years that rang off the hook with false-positives, and I didn't even get a pat on the back at my annual reviews for it.
|
|
#
¿
Mar 9, 2017 20:23
|
|
|
I'd argue that the *real* answer is that labor economics is a complex (and fun) topic. Saying that it's as simple as "government guaranteed benefits is better" is ignoring a lot of that complexity.
|
|
#
¿
Mar 9, 2017 22:00
|
|
|
Give two weeks if you're miserable or you just want to. You won't burn any bridges with two weeks. Give four weeks if you want to. But you won't get enough done even with four weeks to save the company. Don't entertain a counteroffer.
|
|
#
¿
Mar 20, 2017 05:59
|
|
|
Neco posted:Okay now I am curious. Do workers in IT in the US usually get two / a few weeks' notice when they get fired and the employer doesn't absolutely have to (legally)? I guess I have only heard about gross misconduct where people are (understandably) fired on the spot. Not at the low levels. There's no reason to. At higher levels in the org chart things get complicated. You'll often see things like, "Director Bob and Acme Co have mutually agreed to part ways. He'll be staying on till the end of the month."
|
|
#
¿
Mar 20, 2017 21:33
|
|
|
It's an issue of labor economics. It's a complex field, but fun to dig into.
|
|
#
¿
Mar 23, 2017 03:55
|
|
|
Hughlander posted:We upload certs to an s3 bucket and a script pulls all daily and sends out louder and liouder emails the closer they are to expiring. I've still seen certs expire. How does this happen? Isn't there a single person responsible for this?
|
|
#
¿
Apr 4, 2017 19:25
|
|
|
Hughlander posted:In our case there's a company wide certs alias and then it's forwarded to the PO of the product to get assigned. Ah, that makes sense. I didn't consider deployment. I can see that happening at my job too, a story is put on the backlog and yada yada yada a month has gone by.
|
|
#
¿
Apr 4, 2017 19:45
|
|
|
Plus it's better than the alternative. People who talk about how smart they are are the worst.
|
|
#
¿
Apr 5, 2017 01:36
|
|
|
Clanpot Shake posted:Not keeping the test means you trust
|
|
#
¿
Apr 8, 2017 16:05
|
|
|
Why is SVN so bad at merging? Gift holds everything as snapshots, and it does so well. I don't get why SVN never worked as well.
|
|
#
¿
Apr 14, 2017 22:58
|
|
|
Volguus posted:Svn required a certain process to be followed and bit you in the rear end if you didn't. The anecdotes above confirm that. Oh I love Git, but it's definitely more of a toolset that you build a version control solution with. A toolset than includes hammers, screwdrivers, and couple chainsaws. It requires a well defined process and good training more than any other version control I've used.
|
|
#
¿
Apr 15, 2017 01:12
|
|
|
I think it's a question of what you want to track. If you want to track granular changes to code, don't rebase. If you want to track features added, rebase. This is why I say Git isn't a solution to a problem, it's toolbox that let's you build a solution. But you have to decide what you want your process to be, and build appropriately. Git requires a level of customization I never saw in (my admittedly limited experience with) SVN. Hell I'm pretty sure Git was originally built with that in mind. The tools and documentation that it originally shipped with were so minimal you practically had to learn what a blob was before you could do anything.
|
|
#
¿
Apr 17, 2017 17:11
|
|
|
revmoo posted:Yes the hot take where I said it makes more sense to use Git the way it was intended. How outrageous. Go spend time with your families you spergs. Intended is a weird concept. Git was built for people to email patches, which are manually applied by testers and integrators. There's still some nice tools for creating, sending, and applying patches in every installation of Git.
|
|
#
¿
Apr 17, 2017 23:26
|
|
|
Presented without context, from a paper from 1996. quote:Why would the internet community prefer to rediscover and reimplement all the technologies that the operating system community long ago solved?
|
|
#
¿
Apr 18, 2017 15:58
|
|
|
Protip: have your deploy script check the company directory for your name, and abort if it's missing.
|
|
#
¿
Apr 19, 2017 20:58
|
|
|
An old woman is watching the news, and hears that a man is going to the wrong way down the highway. So she calls her husband. "Revmoo," she says, "I just heard on the news that there's a guy going the wrong way on the highway. Please be careful!" "One guy going the wrong way," Revmoo replies. "They're *all* going the wrong way!"
|
|
#
¿
Apr 19, 2017 22:52
|
|
|
vonnegutt posted:Also, devs (myself included) are biased towards preferring features that are interesting to code, don't require weird workarounds, and aren't redundant or repetitive. Stuff like internationalization is always going to be on my poo poo list to build, but I know it's important. I didn't give a drat about Unicode until I heard someone mention that normalization is nearly impossible. Then it piqued my interest. That's the key to getting devs to do something boring. Tell us it hasn't been solved adequately yet.
|
|
#
¿
Apr 27, 2017 18:56
|
|
|
CPColin posted:You can see Experts Exchange doing this, where there's a site-wide stylesheet and a page-specific stylesheet on every page. The latter is generated based on the possible components that can show up on the current page. Which, of course, led to bizarre bugs where a single page somewhere had an overly broad CSS rule that overrode a site-wide style and the bug reports from the users never got specific enough to track down what was causing it. That's a weird choice, given browser caching and modern CDNs.
|
|
#
¿
May 3, 2017 19:20
|
|
|
Being able to train QA and testers, when you have no authority to do so, is a wicked useful skill. Setting up templates like this is a good way to start that.
|
|
#
¿
May 3, 2017 22:20
|
|
|
New Yorp New Yorp posted:This is not as uncommon as you think. Many large enterprises do not use DVCS, especially those for whom software is not their primary business. Think insurance, healthcare, financial industries. I can understand having never *used* it, but having never even *heard* of it is weird for a ten-year software veteran. Not necessarily a deal-breaker.
|
|
#
¿
May 4, 2017 20:01
|
|
|
New Yorp New Yorp posted:Again, not in these types of companies. They don't get exposed to anything outside of what their job exposes them to. They don't care about the industry, or trends in the industry, or the act of writing software in general. They care about coming into work, jamming code into the same codebase they've been working on for the past 15 years, and going home after 8 hours. It's just such a dangerous way to live. I've talked to too many old programmers who did the same COBOL or PL1 work for twenty years, got laid off, and found themselves without the skill set to survive. They skated for a few years in testing, then eventually fell out of even that. The only old and employed programmers I know are ones who either kept learning new technologies, or learned how to manage people. All personal experience, and not enough data points, but it has affected how I manage my career. (Also, I was first exposed to Git at Bank of America in 2007ish. But the guy who set up our workflow there was later poached by Google. I don't know what lesson to take from that.)
|
|
#
¿
May 4, 2017 22:32
|
|
|
KoRMaK posted:Task it out, so that when you do get time you can just work on 30-45 minute tasks. Spend 1-2 hours upfront architecting your tasks, I've set up Trello as a Kanban board for personal projects. It's great.
|
|
#
¿
May 5, 2017 18:06
|
|
|
Jo posted:I think I'm burning out pretty hard and pulling down the rest of my team. Not entirely sure how to broach the subject with my boss. When's the last time you took a real, stress-free vacation?
|
|
#
¿
May 12, 2017 22:24
|
|
|
Rubellavator posted:That was me putting a bookmark button on our portal. Reduced help desk tickets for that issue by 70%. Same, but with a print button. "Can't they just hit Ctrl-P?" "No."
|
|
#
¿
May 24, 2017 21:16
|
|
|
Pollyanna posted:Going home 3+ hours early because there is literally nothing from me to do after a few hours at work (varying reasons) has become the new normal. It feels really awkward cause a few people in the office have a bunch of work while the rest are twiddling their thumbs - they're godawful at balancing work here and it shows. Plus, I've still got the "rear end in chair for 8 hours or you're fired" mentality going. Print up and slowly read up on topics you want to learn. That's what I did for a month. Learned a lot about garbage collection and a little about distributed computing. (Caveat, my contract was not renewed.)
|
|
#
¿
May 30, 2017 22:09
|
|
. I feel kinda guilty, but I prolly shouldn't.
|
Another great reason to interview at one of the giants is the confidence boost. You'll walk into every other interview knowing that you've faced the hardest and didn't crumple.
|
|
#
¿
Jun 2, 2017 18:44
|
|
|
Skandranon posted:I just don't want to go through 8h of being interviewed in a day. It's not too bad. My amazon interview was 5 hours, and after a while it turns into a steady adrenaline- and coffee-fueled marathon. I left feeling like I could tackle the world. (Caveat: I did not get the job.)
|
|
#
¿
Jun 8, 2017 18:12
|
|
|
My sister and I were exchanging stories of stupid arguments in our fields, and I told her about tabs v spaces. Later she said, "Just make a tab equal to one space. Bam. Problem solved." That's my new favorite answer whenever this stupid thing comes up.
|
|
#
¿
Jun 17, 2017 06:22
|
|
|
I use Vi. But that means I also use the command line extensively, including grep, find, awk, dozens of custom aliases and functions. And if those can't do what I want I can build perl one-liners fast. That's what programming in Vi actually means. You're not actually in Vi the whole time, you're using your entire unix environment.
|
|
#
¿
Jun 20, 2017 15:01
|
|
|
Vulture Culture posted:How much you need advanced IDE features depends a lot on the nuances of your language and the standard tooling, also. Like, I've never written Python or Ruby or Golang in Vim and felt like I was missing some key feature that I needed to make me productive, but I'd never think of writing large amounts of Java or JavaScript or C++ using vim. I tend to switch off depending on what I'm working on and how deep I'm getting in the code. (Even in a language that's a bad fit for my Vim workflow, I usually won't fire up an IDE to make a two-line code change.) This is a good point. The Java language, and its best practices, seems to be designed with an IDE in mind. To the point where I tried looking at an enterprise Java project in Vi and my laptop projectile vomited all over me.
|
|
#
¿
Jun 20, 2017 20:04
|
|
|
|
| # ¿ Apr 28, 2024 18:58 |
|
|
Volmarias posted:I managed a massive compensation increase by being hideously underpaid when I first started working in my field. The HR person actually laughed when I asked if they could do better than what I was making. Same. My first job was at a small web dev company that specialized in hiring students right out of college who didn't know any better. No one lasted longer than two years. (And the code base reflected it.) My second job was Bank of America.
|
|
#
¿
Jun 26, 2017 14:58
|
|