|
Far as I can tell the only number colleges look at is how much money they're making.
|
#
¿
Feb 1, 2016 19:24
|
|
|
|
| # ¿ May 6, 2024 11:06 |
|
|
Where I went we actually had to take a Software Engineering course that covered things like overall architecture, readability, and maintenance. Our OOP class also covered some pretty useful organization concepts but in retrospect we just didn't cover enough organizational stuff. I ended up learning it on my own through reading about software engineering further but I cringe at some of the things I saw other students writing. We covered Waterfall but not version control. There were also practical classes like web dev and whatnot but the core was theoretical.
|
|
#
¿
Feb 1, 2016 19:54
|
|
|
ChickenWing posted:Yeah, like just at a fundamental level you should know algorithms if you're doing any sort of programming, and big-O is a fundamental part of algorithms. Big-O is pretty theoretical in its way but where I went there's an entire class on it that only CS majors are expected to know. However, in the second programming class overall there are projects that point out the difference between inefficient, brute force algorithms and more elegant ones. The big one that we went through when I took it was calculating prime numbers. I think that's probably the only thing a programmers needs to know; there are algorithms that work but are impractical but other algorithms that might not be obvious but are way more elegant. The actual analysis class spent like a month on sorting algorithms and their differences alone. We started with bubble sort and then the professor said "never use bubble sort ever." That led into a really in depth, theoretical analysis of how time complexity works and why it's important. Granted he'd also say things like "in the real world you'll rarely need to talk about this stuff but understanding it will make you better at programming."
|
|
#
¿
Feb 2, 2016 18:25
|
|
|
So what do places do with people that don't want to manage and just want to code all day? Seems kind of silly to force them into management.
|
|
#
¿
Jun 20, 2016 12:30
|
|
|
Cuntpunch posted:Someone linked Bob up above, I'll follow up on this conversation with his words of wisdom on the matter: It depends on the school. Java is pretty big and from what I'm seeing a ton of the jobs are java ee Web stuff right now. That's what I ended up doing and I have a cs degree with strong math skills and theoretical fundamentals. From a kind of meh college but anyway... Where I went we did c#, c++, assembly, and Java in the core, required classes. Other classes we did prolog, lisp, and some other odd things. Still we got exposed to a ton of different things. It started with c# though because starting people with C or c++ right now is kind of crazy. Learning to program is hard enough already. No sense staring at slogging through pointers. Then again so many jobs just don't deal with low level stuff I can see why some people didn't learn that. Then again there's also a perpetual shortage of developers in general. Don't like 10% of people working in programming just plain not have any college degree at all? Others were math majors or engineers that learned to code. It's reasonable that a lot of those folks just didn't get exposed to the black magic that is low level code. And why would it matter? Computers are hell of powerful now. If the program does what it is expected to do and doesn't eat all the resources it's good enough.
|
|
#
¿
Jun 30, 2016 04:09
|
|
web developers
|
GlitchThief posted:I'm a self-taught web developer who has been working professionally for six years. Can I be a good programmer if I study C++, or is it too late for me? That depends on if you're willing to learn its quirks. Learning c++ takes more effort than learning html. It probably isn't too late you just need to read about the language, pointers, memory management and such. The biggest issue comes from people that make assumptions. Don't make assumptions about c or c++. So many things don't work the way you'd expect. But really if you're willing to put in the hours and work with the language rather than against it you'll be fine. Then again this is coming from somebody that dislikes c++ and sticks to things like c# or java so take that as you will.
|
|
#
¿
Jun 30, 2016 18:25
|
|
|
Just put all the candidates in a room then put the interviewer in the middle and blindfold him. Spin him around a bunch then have him try to walk in a straight line. First candidate he blunders into and knocks over gets the job.
|
|
#
¿
Jul 3, 2016 16:09
|
|
|
Pollyanna posted:Knowing when and where to draw the line is basically the holy grail of software development. I'm not surprised that they don't know how to do it. I've also noticed that playing into that is the fact that literally everything is a tradeoff in software. It's important to weigh the pros and cons, especially long term, but how many people either misjudge them or just don't consider it at all?
|
|
#
¿
Jul 14, 2016 18:50
|
|
|
So at work the pages are modular; there are a bunch of headers that are attached to pages before the body. One of them is called [...]NoScript as it's a version of [...] that doesn't use JavaScript. ...the only things it's attached to use JavaScript very heavily. In fact they're some of the heaviest users of JavaScript in the whole thing. They're also some of the only pages that only use one type of JavaScript. Others have multiple, conflicting frameworks crammed together.
|
|
#
¿
Jul 21, 2016 03:31
|
|
|
Bruegels Fuckbooks posted:This is sadly rhetorical, but why is this a technology problem? Why not roll back the changesets of people who do this and fire people who don't look at the things they check in? Nope, clearly the answer is branches and unit test guidelines with code coverage percent thresholds, instead of just not hiring morons. It's cheaper to hire morons. There's also a shortage of programmers on the world in general so good luck getting the best ones. Sometimes you just have to make do with what you can get.
|
|
#
¿
Jul 21, 2016 18:13
|
|
|
I think a lot if it depends on how much you like to code as well . I greatly enjoy programming and can easily do it all day. Businesses want people like that only to recruit them, force them to grind 70 hours on things they aren't interested in, and micromanage them to death. As much as I like doing it all day some days I'd like to play a video game or spend time with a nice lady I'm fond of every now and again. Plus nobody can keep that up long term. Permanent crunch is awful even if you like it. A lot of people are meh on the work and just want to do 40 hours for a paycheck. You can't force those people to enjoy 16 hour coding sessions. Granted a lot of it is tied up in MBAs who want to quantize everything and ignore intangibles. Working everybody that is salaried exempt for 15% more hours will mean 15% more work done for free, right? Hey why are all our developers quitting?
|
|
#
¿
Jul 26, 2016 18:31
|
|
|
Pollyanna posted:This is 100% all the MBA's fault. I do the maths that make the moneys go to me I think the funniest thing is when an MBA decides that inexpensive programmers are just as good as expensive ones and hires whoever will do the job for $30K, only to find that it costs them more in the long wrong to have a more expensive programmer clean up the mess later.
|
|
#
¿
Jul 27, 2016 04:36
|
|
Also gently caress you if you aren't working 24/7/100% you lazy fucker you're fired.
|
ratbert90 posted:He's not wrong. Take a wild guess how soon there will be time found for refactoring. "We'll make it suck less later when we have time" is a leading cause of technical debt.
|
|
#
¿
Jul 29, 2016 17:18
|
|
|
ChickenWing posted: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. Yeah after all the time I spent in retail and the restaurant world I'm used to panicking about everything, all the time. I had something come up yesterday that I had to take care of before 4 p.m. I e-mailed my boss and was like "hey can I take a long lunch to take care of stuff and then just stay late to do my work?" His response was basically "it's cool, get it taken care of" and then on his way out ask me if everything was fine. It's a first world problem to be sure but it absolutely amazes me how loose everything is at my job and I'm honestly having trouble adjusting to it. I'm accustomed to places that will write you up or fire you for taking a 16 minute break instead of a 15 minute one. Now as long as I show up every day and do something useful while I'm there everything is gravy.
|
|
#
¿
Aug 5, 2016 02:23
|
|
|
That sounds to me like they like you and might be offering you a job some day.
|
|
#
¿
Aug 9, 2016 18:49
|
|
|
It's also just plain hard to perfectly quantize development. Sure anybody experienced and worth their salt can give you estimates on how long it will take but, well, sometimes poo poo just goes wrong and that easy three hour task turns into a time devouring behemoth. Which then breaks some piece of legacy code that an intern wrote six years ago and never documented but when you fix that a security hoke crops up anddd.........
|
|
#
¿
Aug 16, 2016 18:22
|
|
|
Cirofren posted:It's not like anyone's measuring lines of code per hour anymore (I really hope.) At work I had to come up with a set of goals that I'd try to work at. One of the suggestions was "lines of code per day." I just went  when I read that because it's just so profoundly stupid. That and I'm negative on that metric because some of the first tasks I got at work were along the lines of "there is a poo poo load of bad, old code for bad, old features we don't use anymore. Spend a few days being a software janitor and yank that crap out."
|
|
#
¿
Aug 22, 2016 08:39
|
|
|
leper khan posted:On the other hand writing tests after the fact without a target code coverage metric has provided more insightful tests than TDD in my experience. A very, very useful thing with tests is in automated testing; sometimes one change you make breaks something else but you basically just kind of can't plan for everything by yourself. So you call up your bro Jenkins, give him a ton of tests, and say "hey man let me know if anything is indirectly broken by this." If a test that has passed the past 300 times it was ran suddenly started failing that should get some attention so you can figure out why.
|
|
#
¿
Aug 23, 2016 00:51
|
|
|
My Rhythmic Crotch posted:My favorite so far is a project dreamt up by a junior guy. It had about 15 dead code paths, each due to using == instead of .equals for string comparison. To be fair though that's an easy mistake to make that can be explained by inexperience. I kept making that mistake at work because there I write Java but came from C#. stringOne == stringTwo is a comparison in C# but is a reference equals in Java.
|
|
#
¿
Aug 27, 2016 17:59
|
|
|
Cuntpunch posted:Someone keep me honest here, but I thought the variance in behavior(compared to Java) is because *it doesn't matter* in C# due to the fact that identical strings are aliased under the hood? A quick peek at Linqpad suggests this to be true - ==, Equals(), and Object.ReferenceEquals() will all return true for two strings with the same value. In c# strings are a primitive type. In Java they are not. In Java == is a reference comparison for string objects. That's the big difference; this is why == works that way for ints in both langauge.
|
|
#
¿
Aug 28, 2016 17:47
|
|
|
csammis posted:C# strings are not a primitive type. OK no you're right; I should have clarified that they behave like one. Strings are kind of bizarre from a programming standpoint.
|
|
#
¿
Aug 28, 2016 18:21
|
|
|
revmoo posted:Home Depot uses that word too. One of my first jobs was "Lot Associate" which is somehow more demeaning than "Cart Bitch" Walmart does similar things; pretty much everybody was a "sales associate" as their actual job title. You could get more specific and be all like "I'm a dairy associate!" or something. A few jobs were just the job like "unloader" was a guy that unloaded trucks. But really anybody that wasn't below a department/shift manager was a cashier, unloader, or associate. Somehow calling somebody that stocks shelves a "sales associate" doesn't seem quite right. When I quit that job I was still a "sales associate" even though I was quite often hiding in the back sorting freight. leper khan posted:I love how associate means partner in law offices and intern in software. Let's also not forget that sometimes an entry-level programming position might still have the word "engineer" in the title. Or you might work at a place that hires developers but none of them are "engineers." Or the IT guys will be called "engineers" while the software guys are "developers." Who the hell even knows?
|
|
#
¿
Sep 19, 2016 23:49
|
|
|
I suddenly feel quite happy that the company I work for's policy on that sort of thing is "we don't give a poo poo what you do in your spare time. Get another job, do side work, whatever...just don't work for somebody that competes with us." I just have to  so hard at a company that says if you write code for them and go home and write a book they own it. To me that's an enormous "DO NOT EVER WORK HERE" sign.
|
|
#
¿
Oct 1, 2016 04:31
|
|
|
Cuntpunch posted:Eh, I once pushed back when an employer tried to introduce a "everything creative you do is ours" contract, with a retroactive clause. I'm more than happy signing over "hey, anything I do with SOFTWARE that possibly pertains to WORK STUFF is yours" contract, because it makes sense. But as soon as it encroaches on "I write software as a profession, but if I write a novel in my personal time, the company owns it" type territory, I get reasonably defensive. And I haven't seen another contract yet that attempts to enforce ownership on *all* creative works, except those that possibly have anything to do with my actual job, which is fine by me. Yeah that at least makes sense; where I'm at it was pretty similar coupled with a "do not work on outside things on the job and do not use company resources for outside stuff." I don't remember all the details because I read every word, though "well that's reasonable," and signed for the job. They own everything I do at work which is fine and I have no idea what the hell I'd use the thing I work on at work for anyway. I'm not a lawyer but I think that's the baseline of IP law anyway; if somebody pays you to make something they own it by default unless a contract specifies otherwise.
|
|
#
¿
Oct 1, 2016 17:57
|
|
|
ChickenWing posted: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. Sonar is more of a reminder not to code like a dumbass. Cyclomatic complexity is a big one; you might think you'll remember what that horrifying mess of if statements, for loops, and switches does but come back to it a year from now. You won't. Worse yet somebody else might have to untangle that mess. Beyond a certain point it's best to refactor it somehow in combining if statements or just chunking it into functions that have a lower complexity. Keeping that stuff low makes code more maintainable and less bug prone. Sometimes it's just plain unavoidable so you can tell Sonar "yeah just ignore that." In some cases a cyclomatic complexity of 15 to 20 is perfectly fine but as a general rule you should avoid getting above 10. Other stuff is just little reminders of better ways to do things; isEmpty() is a perfect example. Nested ifs and fors are another; going more than 3 deep is just ugly and unreadable. It will probably function but break that stuff apart. Generally speaking the view should be "I'll not do these things in the future and will fix old code as I have time." But, like was said, a class that Sonar finds 50 problems with is probably a horrifying Codethulhu that will haunt your dreams and devour your soul. Probably the most important thing that Sonar reminds you to do is thrown meaningful exceptions. Just throwing "exception" isn't a good idea; it should be an indicator of just what went wrong so that way when it does go wrong (remember, it's not if your program crashes it's when) you have a good indicator of just what did go wrong and have an easier time tracking it down. You won't ever learn all of the rules and you do still have deadlines but Sonar is helpful.
|
|
#
¿
Oct 18, 2016 03:31
|
|
|
MisterZimbu posted:Even so, the clause in this contract indicates to me that they previously had a problem of developers getting the gently caress out early on in their employment. If there is any possibility of a job netting you negative pay you walk. End of story. A clause where you have to pay them recruiter costs back is that possibility. It absolutely sounds like a solution somebody came up with to force people to stay rather than convince them to. I'd have walked on seeing that too. No questions asked. Just gone.
|
|
#
¿
Nov 4, 2016 22:36
|
|
|
metztli posted:For businesses with exceptional volume and potentially huge consequences at this time of year, a freeze makes perfect sense. We want to minimize the chances for something to go wrong in production, and no feature we might release is worth the potential headache. I imagine that also depends heavily on what kind of software you're making. You absolutely do not want to have your point of sale cash register software that fuels any store at all go down any time during the holiday season. Same goes with inventory, tracking, or accounting software.
|
|
#
¿
Nov 25, 2016 03:24
|
|
|
One real problem with UI design is that somebody with design skills probably lacks technical skills while somebody with technical skills probably lacks design skills. People with both are pretty hard to come by.
|
|
#
¿
Dec 23, 2016 03:20
|
|
|
Agile failures will never cease to amuse me. The entire point of agile is that you should be adaptable and change as the conditions do. Yet so many of the stories are "we will do agile in this extremely rigid way. Here is our agile process, which is set in stone and will never, ever change."
|
|
#
¿
Dec 28, 2016 02:21
|
|
|
Gildiss posted:Once had several stories where the description was just the vague title stated again. With priority 1. Everything was priority 1. The dumbest thing I saw at work was something labeled "high priority" that I was told had to be done quickly because it was a huge deal. So many things going on at work were going to rely on it. It was put on the issue list with a due date of October 31. Well, guess what? I finished it on October 17. It still hasn't been code reviewed at all. It's just sitting there in the queue waiting to be looked at. Pretty annoying but I just kind of shrug about stuff like that at this point.
|
|
#
¿
Dec 31, 2016 22:48
|
|
|
The core problem is that you have people who want to measure and quantize something you can't measure and quantize. Development is a creative process with a gently caress ton of variables. The boss wants a hard set of numbers but actual developers know that you can give estimates at best. There is just no simple measure of anything.
|
|
#
¿
Jan 4, 2017 19:44
|
|
|
Sometimes bugs also come up because that one library when updated decided not to play nicely with that one other library. Or that one hack you did that got everything working 100% of the time at that time turns out to only be 99% effective two months later. Other times you had a tight deadline coming up so you cobbled together anything that works as desired. Hell other times a hardware upgrade makes everything explode. Other times it's just plain ol' human error. Making bugs "very rare" is a pipe dream for anything more complex than a hello world. Anybody who believes bugs can be totally prevented or eliminated doesn't understand what programmers do. A significant chunk of what programmers do is fix inevitable bugs.
|
|
#
¿
Jan 5, 2017 04:58
|
|
|
One of the core problems that can probably never be fixed is the fact that people hiring coders often have no idea what coders actually do. I'm quite glad my boss is a huge tech nerd because, well, sometimes a programmer is sitting in his cube looking like he's just staring off into space. OK, that is sometimes what he's actually doing but other times it's turning over options in one's head and considering tradeoffs. Sometimes I'm trying to come up with an algorithm to do something. Other times I'm hunting a bug and trying to figure out just what the gently caress caused it. There is never one "best" answer and no code is ever perfect. It just isn't easily predictable what bugs will crop up, when, and what will cause them. Sometimes production grinds to a halt for a week while the team tracks down some bugs that absolutely must be fixed before anything more goes in. Every decision has ramifications and you have to end up planning for that. The other thing is technical debt. Technical debt, if you don't fix it, collects interest. That small pile of debt right now can very easily totally cripple the whole operation if you ignore it for a year but the boss only gives a poo poo about numbers. Fixing problems and reducing technical debt isn't adding new features and new features are what we sell. Plus every single time you come up with any sort of metric to measure the productivity of a programmer you have put a system in place that can be gamed and somebody will game it. This is especially true if you put programmers in competition with each other in any way.
|
|
#
¿
Jan 6, 2017 07:11
|
|
|
Munkeymon posted:My current employer switched to FinancialForce this year and boy howdy it must be nice to write software that the purchaser never has to use. I mean, except that you end up with a SalesForce-shaped stain on your resume, but I guess some people are into that? Name recognition, I imagine. SalesForce is a steaming pile but some HR person that knows absolute balls about technology could see that and go "oh I know what that is" or "we use that I shall put this in the pile" and get you past that filter. Iverron posted:I moved offices the other day and warned the other guy I now office with about my doing this. Turns out he's the same way. All of my coworkers sound like sailors pretty much. I was kind of worried that I'd let some profanity slip and get reprimanded/fired. I tend to swear a lot but can keep it under wraps 99% of the time when necessary. Then my boss said "gently caress" about 40 times in a meeting. We tech nerds basically have our own wing of the office that's pretty separate from sales and whatever. People that swing by for whatever reason apparently are well aware that this is our territory and we'll loving talk the way we drat WELL please. Some places just don't give a crap about swearing. I think this especially applies to tech pros because what techies deal with is frequently frustrating and rage-inducing. One of our top techs is...very passionate. I hear him punch a wall about once a month. He's actually a really nice guy otherwise but does he get livid at big enough problems. I've never seen him get mad at people but devices sometimes piss him off.
|
|
#
¿
Jan 12, 2017 05:51
|
|
|
lifg posted:Alternately, you can have a fixed scope or fixed date. It can have any deadline you want if it isn't required to function.
|
|
#
¿
Jan 19, 2017 21:55
|
|
|
Destroyenator posted:I've seen resumes with keyword sections divided roughly as "strong in", "capable in", and "interested in". It's a good way to show you're doing more than one thing but are self aware enough to rate yourself. Is there any general way places prefer to see that organized? I've just been saying "main things" and "familiar things." Main languages and technologies are anything I've done something significant in and use regularly, either at work or for my own projects. Familiar is stuff I've used or read about but haven't used a ton. Does that sound appropriate?
|
|
#
¿
Jan 24, 2017 21:05
|
|
|
AskYourself posted:If you like to see it this way : because onboarding new hire and getting them up to speed at a good productivity level cost the company more than 2 months salary. So if the sick employee is a good one it's a better financial choice. The other thing is that if you want top programming talent what you need to offer is literally "all of the perks." Granted various types of disability insurance generally come bundled with medical insurance in the states already. Like was said it's mandatory in some states but even where it isn't you can probably get it, often just as a consequence of getting a job. The simple fact is that people get sick. Granted lovely companies will just plain not authorize it sometimes but those companies are poo poo and you want to work for less poo poo companies.
|
|
#
¿
Jan 27, 2017 06:04
|
|
|
Volmarias posted:Everyone else has already posted pretty well, but I'd like to also point out that in the US, there's no laws giving mandatory time off. There are national holidays, but those rules only affect non-exempt workers (so basically no computer people). If you're salary exempt, your company could theoretically demand that you work every single day, weekends included, with no time off whatsoever. McDonald's was notorious for that. We're talking $25,000 a year with awful benefits to work 90 hours a week. The food service world had that poo poo utterly rampant. Your job was your whole life at that point. You'd see managers on the end making less than the hourly minimum wage because lol gently caress you. For every person who got sick of it and quit there were a horde of people with kids to feed happy to get the bump up in yearly pay. Of course it was Texas that challenged the change. Labor laws in the U.S. are pretty bad.
|
|
#
¿
Jan 27, 2017 17:59
|
|
|
Fellatio del Toro posted:Does anyone's office not basically shut down the last week of December? All my jobs have allowed carryover and it's still always a ghost town between Christmas and New Years. We didn't completely shut down but given how many people take long vacations around the holidays it's "don't do anything that makes a big change," basically. But yeah the office was basically half empty for 3/4 of December.
|
|
#
¿
Jan 28, 2017 00:19
|
|
|
|
| # ¿ May 6, 2024 11:06 |
|
|
The agile philosophy is good and all but the issue is that you often get That Manager that wants a very quantized, easily measured, highly specified set of expectations from developers, which just isn't possible. Yeah a competent developer can guess how long something will take but a competent developer will also tell you "poo poo will go wrong." That five line change might turn into a week long hunt for a Heisenbug that totally cripples the application from time to time but is so hard to duplicate and oh gently caress this critical system was written 8 years ago by an intern why does this abomination even exist in production? I can't make this change without fixing this and...ugh. ... Not that I had a relatively small thing to do at work that turned into gutting and rewriting an entire system. No. That didn't happen to me at all!
|
|
#
¿
Jan 31, 2017 05:26
|
|