|
If your point of reference is mediocre mobile hardware, I can more readily see the appeal of 'rent-a-box' coding experience. I really don't think I could deal tho - It'd probably be enough for me decline an offer.
|
#
¿
Mar 20, 2022 11:08
|
|
|
|
| # ¿ May 9, 2024 20:55 |
|
|
ExcessBLarg! posted:For personal use? Sure! As a salaried, but remote professional I'm not hosting a big, power-hungry work machine at home. I already have enough low-power hardware at home for product testing that takes up a bunch of space I'd rather it not. If my responsibilities were solely in development though, nope. This is very interesting to me - myself and my friends who've worked in this space have basically always wanted the fattest, biggest box we could get. I think I said this previously in this thread, but I was borderline pissed when my current job handed me a MacBook when what I really wanted was a powerful desktop. I'm not that familiar with the perspective of solving for space or mobility vs solving for 'needs to do all the things the fastest'. I can at least understand here why they would distribute mobile hardware as a primary device, since a sizable portion of this thread seems to prefer that.
|
|
#
¿
Mar 20, 2022 21:11
|
|
|
ExcessBLarg! posted:A workmate of mine once expensed the largest, beefiest laptop he could find because he needed a machine that was portable and one that could compile the "entire" codebase in minutes or whatever. That machine was a nightmare. It was big, heavy, hot, loud, and routinely broke down. Since he could do all his development on it, he ended up developing only on it and transitioning to other machines wasn't as fluid as you'd hope. I still don't know how he ever traveled with it. One day, his itself-a-laptop-sized power brick shorted out and took the entire machine with it. That was not a productive day. I will say that I think unless you have an outstanding reason, building out a massive laptop is usually a mistake. Mobile hardware just...sucks. Even 'good' mobile mobile hardware is hamstrung by the space constraints in it, which end up manifesting as thermal limits, or unintuitive bottlenecks, etc. etc. Also, *insert complaints about keyboards and displays*. I really insist on desktop hardware as a result. Everyone get a big box :P.
|
|
#
¿
Mar 21, 2022 18:41
|
|
|
Slack is pretty poo poo, but the fact that it can't exist in more than one loving window is beyond a joke. Trying to piece together information from more than one message is a nightmare. Slack UX is dogshit phone-tier garbage.
|
|
#
¿
Apr 4, 2022 20:02
|
|
|
I've not worked in a space where we would outsource code, but literally every time I've had to work without outsourced code, it's been a disaster and would almost have always been cheaper to just hire a quality firm state side to get the desired result. My favorite story here is a Power Utility that purchased a whole cooperate internal website for low seven figures, and proceeded to ditch it after 2 months because of how nonfunctional it was. Every story I have is more or less theme and variation on the same thing.
|
|
#
¿
Apr 13, 2022 19:36
|
|
|
ExcessBLarg! posted:It is xenophobic though, unless (i) you're already familiar with a specific off-shore team known to be yes-men, or (ii) you do a quick understanding check for all new teams you interact with, not just the offshore ones. I have a bit of a hot take. I do not assume offshore developers are bad because they are offshore. I assume they are bad because they are cheap. I also assume domestic dev houses are bad if they charge $900 / dev week. There are exceptions. There are certainly people in these dev houses that are probably pretty good, who are trying to break out and find a company that more aligns with their skill level, but an outsourcing manager can't spend their time trying to figure out which studios and which individuals within those studios will be able to turn around good work. If I was the one making a call on this, I'd probably suggest we just hedge our bets, hire a well known entity in NA or EU, and call it a day.
|
|
#
¿
Apr 21, 2022 19:33
|
|
|
ExcessBLarg! posted:Isn't this literally the job of an outsourcing manager to figure out though? OK, actually think about this problem now. How do you *possibly* do this with any level of reliability? What questions do you ask? How do you make a good evaluation? Here's a fun story: I have a friend who works on a public-facing service that tried to outsource their QA effort to a Chinese firm ("Look at how much we can reduce our QA costs!"). They evaluated them by asking them to do exploratory testing on their live product and to put in bugs. Impressions were positive as they sourced quite a few legitimate bugs. Firm gets hired. After a whole quarter of paying this firm to do QA work, they put in a grand total of SEVEN bugs. They found more bugs in the public facing service then they did on in-development builds. An investigation was done and it turns out they just scraped bug reports from reddit etc. during their initial evaluation. There is no good way to evaluate these firms without having them do spec work, which is it's own problem. If I heard from a someone I knew and trusted in the industry that some overseas firm did good work, I'd at least consider them, but it is a veritable minefield. It has nothing to do with race or country of origin and framing it as such is pretty silly. I wouldn't hire an overseas firm for the same reason I wouldn't hire a brand new firm with no verifiable work out of Silicon Valley: It's super risky (and in the case of the Silicon Valley firm, probably also super expensive). Canine Blues Arooo fucked around with this message at 21:07 on Apr 21, 2022 |
|
#
¿
Apr 21, 2022 21:04
|
|
|
It's already been said, but it bears repeating: The best way to architect stuff is to just do it, suck at it and feel the pain, attempt to solve the pain with better solutions (which means homework), and then redoing it. You'll eventually default to 'good' solutions and have a sense for when something is going the wrong direction.
|
|
#
¿
May 27, 2022 19:05
|
|
|
asur posted:Why would you try to kill a pet feature of the CEO or management in general? It's not your money, who cares if they waste time or resources on it. Some people actually want to believe in what they work on.
|
|
#
¿
May 30, 2022 20:41
|
|
|
CPColin posted:I have a few separate web applications that share the same magic string values. They can technically be anything, as long as they match. I keep having a tendril of thought go, "These values should be in a library!" until a louder thought goes, "gently caress that!" and I just drop another "keep this in sync with (other application)" comment. Is there a reason these can't these just be a few lines in a DB? A library is going to be a mess if you have to update those strings and you are just waiting for problems to show up when someone forgets to update the library. A microservice is hilarious overkill to retrieve a few strings and is over-complicating this problem for no reason, is extremely expensive to build, host and maintain (relatively speaking). There are other details to consider as well here: How are these strings created? If they change over time, how frequently? How many apps are we talking about - 3? 10? 300? Canine Blues Arooo fucked around with this message at 20:10 on Sep 1, 2022 |
|
#
¿
Sep 1, 2022 20:03
|
|
|
If they truly never ever change and are few in number, then a const in each codebase would probably be where I would go with this. If they are more numerous but would change, I'd put them in a DB. This doesn't sound like it requires a complex solution.
|
|
#
¿
Sep 1, 2022 20:23
|
|
|
prom candy posted:What service should I use for consolidating all my logs from my various applications/k8s/etc.? I'm using LogDNA right now but I don't like it all that much. Bonus points for being dead easy to use and not making me think very hard. How many logs / day? If it's not millions, then I'd say just stand up a mysql / postgresql / something and write to that. That's a pretty trivial, controllable solution.
|
|
#
¿
Sep 16, 2022 03:44
|
|
|
steckles posted:I always figured that places hiring this way would be lovely places to work. Turns out that one of the devs we lost this way has reached out about re-applying with us and they don't have nice things to say about their new company: Long hours, disorganized, high stress, high turnover, no direction. She disliked it enough that she's willing to take a pay cut to come back. People should be able to pursue whatever job opportunities they want, I'm at a loss about how to prevent this. I see this happen for one of three reasons: • Compensation • Passion • Opportunity Compensation is really straight forward. Are you actually paying competitively? Someone offered me a senior position doing .NET work for $110k and they insisted they were paying competitively. Make sure you actually know that Passions is also really straight forward. Someone working in Finance gets an offer for Games or whatever and they are willing to take a pay cut to go work in the thing they REALLY want to work on. Not much you can do there. Opportunity is the sneaky one that everyone seems to forget. The current wisdom in the industry is to not get married to a company because you should be looking to jump ship as soon as your skills are developed for 'the next level'. Waiting for a promotion and a reasonable raise is a fools errand. With that said, what's your policy for promotion and raises? Are you actually promoting people based on their skills and not based on their time employed? Do you have a good way of recognizing those who are contributing the most, and avoiding promoting those who are just sucking manager dick? These are hard problems to solve and they frequently go un-solved because it's generally expensive to solve them and the hedge here is that the majority of people won't be willing to uproot their life to get a promotion by proxy. Employees are not blind to what the promotion schedule and policy actually is in practice, and people talk. I recently did this to my employer, jumped ship, and then came back and got a way bigger pay increase then I ever would have if I just stuck around. This was very expensive for the company and a huge waste of my time but 'Play stupid games, win stupid prizes.'
|
|
#
¿
Sep 22, 2022 06:15
|
|
|
Honestly, there are zero good chat / voice apps. Each one seems to have it's quirks and stupids. Slack is probably the closest but a web guy ended up as the designer, so it's UX is hosed for anything that isn't trivial and it's slow as gently caress - not being able to split out channels into their own windows is a huge throw. Teams is a never-ending pile of work arounds and compromises it seems. I haven't used it through for 3~ years. Discord has the same UX issue as Slack and just doesn't scale to 'I need to have context of several conversations at once'. Skype is the worst.
|
|
#
¿
Oct 13, 2022 18:22
|
|
|
New Yorp New Yorp posted:Money? Adjacent to this: I'd imagine there are some engineers are who are pretty frustrated that Twitter basically delivers no meaningful features to it's users like...ever. If Elon is seen as a herald of changes to come in that regard, it might be exciting for some of those folks. Besides that, it's the devil you know and all that. And Money.
|
|
#
¿
Oct 29, 2022 22:26
|
|
|
prom candy posted:What's his forums username Alternatively, buy him an account.
|
|
#
¿
Jan 6, 2023 07:01
|
|
|
I'm not gonna lie. I know pretty much gently caress-all about how to use git CLI and have been working off of either Github for Desktop (which is pretty decent as far as modern software goes) or when I'm stuck on SVN, I deal with Tortoise. It is completely absurd to me though that there is some weird expectation around 'knowing git' in this world. Yes, you should probably understand what the git words mean and how they map to functionality, but to be able to use the CLI is silly (unless automation around git is part of your day to day). I'm using this as a proxy for an argument that irks me quite a bit: There is still this weird ideology around CLI software that it is somehow 'better' - it's spoken about in almost romantic terms. I find this thoroughly absurd. CLI is a great feature set for certain use cases, but rarely for a human, and I don't take the suggestion to learn the git CLI very seriously. Of all the things I could actively learn, CLIs are such an enormous waste of time...and I don't really know hot hot of a take that is anymore.
|
|
#
¿
Feb 21, 2023 07:26
|
|
|
I've been using ChatGPT mostly for medium complexity syntactical questions, and some random debugging. It does a very decent job in general, and while it sometimes has errors, it's close enough that I can plug the holes myself. It's more or less replaced Stack Overflow for me.
|
|
#
¿
Feb 22, 2023 06:29
|
|
|
The killer feature of Github for Desktop is definitely seeing all the changes you've made *right there*. I'm immediately real sad when I don't have that.
|
|
#
¿
Feb 26, 2023 21:27
|
|
|
C# is my husbando - git is just my side gig, ya know.
|
|
#
¿
Feb 27, 2023 06:35
|
|
|
Does anyone actually have a test suite that they'd call 'complete'? I've never worked on a project where our testing was that complete, and my current project has the most complete set of tests I've ever seen, and it's hardly exhaustive. To that end, I could see some fear about ChatGPT or CoPilot writing 'bad' code for a complex project. I use it a lot for syntax-like questions (and it's awesome for that), but I would not copy/paste whole methods or even substantial chunks into the code base without careful review.
|
|
#
¿
May 25, 2023 23:31
|
|
|
Bongo Bill posted:I would simply write good code instead of bad. 
|
|
#
¿
Jul 12, 2023 00:45
|
|
|
There are times when I really wish my app dev life was just WPF on top of C...somehow. I love C#. My default starting point for any new project is, 'why SHOULDN'T this be C#?' and I pretty much always come back with C# as the answer, but C# can get really, really complicated. Not C++ complicated thank god (or at least not in the same ways), but the tangled web you are allowed to weave with it's bottomless feature set is quite a thing, and C# 12 is just gonna make that poo poo worse. Every new version comes with really cool features that I love to think about and toy with, but the second you apply them at scale on a code base being touched by dozens, it makes it really hard to figure out what the hell is going on. The balance here that I think is not being struck on the project development side is, 'powerful new features that enable a highly extensible code base' vs 'the practicality of training people on this code base'. When you ultra seniors are allowed to architect, this massive pool of features lets you over-engineer like crazy, and then training up new people becomes very challenging. Basically, what I'm saying is that we should just go back to goto everywhere, obv. Canine Blues Arooo fucked around with this message at 20:30 on Jul 12, 2023 |
|
#
¿
Jul 12, 2023 20:27
|
|
|
DELETE CASCADE posted:i remember learning three key principles of oop: encapsulation, polymorphism, and inheritance I wasn't in the industry as OOP became The Thing™ - I was born into it being the defacto, so my perspective is skewed here, but my take is that things like Inheritance becoming a staple pattern of OOP in it's hayday meant that everyone seemed to want to turn every problem they could into a nail that the Inheritance Hammer can smash away at. I don't think Inheritance necessarily is bad on it's face - it's a feature with tradeoffs, and ought to be wielded carefully. Maybe more carefully then it has been in the past.
|
|
#
¿
Jul 16, 2023 05:26
|
|
|
epswing posted:Yeah, it's tough. On one hand, without writing code in the interview, it's very hard to gauge if they can do the job. On the other, it's hard to write code and think straight under pressure which you'd almost certainly never experience on the job. In an interview setting, I would definitely probably write out the expanded version of this with a comment saying, 'You could .Sum this, but I assume we are going to expand functionality'. I'm more and more inclined to write increasingly verbose code that is easier to understand per line. It's easier to revisit. It's easier to train on. It's easier to expand. It's not as sexy and if your team is senior, it takes longer to write, but I'm appreciating more and more the value of writing naive code where it makes sense to do so. Writing the coolest, sexiest code in the fewest number of lines is not the way I'd choose to do thing. I need to write maintainable stuff, not win at code golf.
|
|
#
¿
Aug 22, 2023 23:03
|
|
|
Slack is loving terrible and I can't believe I'm actually excited to move to Teams. It's not like Teams is much better, but it's a step up.
|
|
#
¿
Mar 12, 2024 18:57
|
|
|
redleader posted:this will be the state of ai forever, barring some radical new approach. get used to it Basically this. Also, it likes to hallucinate just as much as everything else in AI. i've gotten some mileage out of Copilot, but it's not ever going to solve 'big problems'. It's going to write out some LINQ that I don't have to construct myself (which is nice).
|
|
#
¿
Mar 27, 2024 03:14
|
|
|
|
| # ¿ May 9, 2024 20:55 |
|
|
Clanpot Shake posted:MBAs will do anything to not pay down tech debt I mean, if your company is hiring MBAs for literally anything they deserve to fail.
|
|
#
¿
Apr 13, 2024 21:08
|
|