|
FYI to those who were assisting me earlier: I think parts of what were said to me are just now finally registering in deeper parts of my brain.
|
#
?
Jun 11, 2015 00:49
|
|
|
|
| # ? May 23, 2024 18:04 |
|
|
comedyblissoption posted:to be fair, it solves the problem of getting novices to work w/ toy programs w/ minimal knowledge this is true. shame they turn around and use it in production.
|
|
#
?
Jun 11, 2015 00:50
|
|
|
unfortunately such a decision can have awful effects once you move beyond a toy program i think a lot of damage has been done in the computer industry based on showing trivial toy examples and people not asking how such an approach might scale in complexity edit: where complexity here means program complexity
|
|
#
?
Jun 11, 2015 00:50
|
|
|
Subjunctive posted:you solve that by firing people who are bad, though, not anchoring someone's salary in a bad spot. IMO! there is a distinction between "too bad to pay any money to at all", "bad, but still better than not having anyone in that slot at all", and "actually very good" the latter is rare enough even among people who have actual experience; most people you hire with no experience are going to fall into one of the first two buckets. given that, "anchoring" their salary at the lower level seems fine, as long as you recognize when someone has proven themselves to be a B or A player and are willing to adjust their salary to match (otherwise they will just leave as soon as they have enough experience to get other offers) obviously you'd like to form a team of entirely the latter group but that is basically impossible even if you are a megacorp with a massive talent pool to draw from, let alone some lovely small company
|
|
#
?
Jun 11, 2015 01:01
|
|
|
Fanged Lawn Wormy posted:FYI to those who were assisting me earlier: it takes time to acquire a framework for even beginning to understand this kind of thing, to be able to ask meaningful questions and understand the answers keep bashing your head on it and eventually things will begin to make sense. then you will look at your old code and react with disgust, and want to rewrite it all in the way you now understand to be best. this will happen basically every time you go back to some code you wrote more than about two months ago. this will keep happening essentially forever. if it stops happening, you need to find something that you aren't comfortable with and learn to do that
|
|
#
?
Jun 11, 2015 01:07
|
|
|
Dessert Rose posted:there is a distinction between "too bad to pay any money to at all", "bad, but still better than not having anyone in that slot at all", and "actually very good" yeah, you're right, probation -> {fire, salary-adjust} is better, but most managers don't have the autonomy to operate that way. keep rockin', luigi, and make sure you're learning stuff the next company will pay well for.
|
|
#
?
Jun 11, 2015 01:08
|
|
|
starting to actually find powershell and .net enjoyable, send help
|
|
#
?
Jun 11, 2015 01:27
|
|
|
uncurable mlady posted:starting to actually find powershell and .net enjoyable, send help dont know poo poo about the former but congratulations on your correct experience of the latter comedyblissoption posted:im honestly a little bit baffled how dynamically typed languages are actually getting more popular than statically typed langs it's because dynamic typing lets me move fast and break stuff.
|
|
#
?
Jun 11, 2015 01:40
|
|
|
dynamic typing lets me feel more productive because it doesn't break until i run the app and sometimes it doesn't break until i ship it to customers! that's definitely better than having to silence this dumb thing that keeps whining about "types" and "mutability"
|
|
#
?
Jun 11, 2015 01:47
|
|
|
"what is the borrow checker and why is it keeping me from shipping RCEs?"
|
|
#
?
Jun 11, 2015 01:50
|
|
|
I am dealing with css the rest of the week. yippie.
|
|
#
?
Jun 11, 2015 01:54
|
|
|
im writing less stylesheets for each of my knockout components. it sounded good in my head but idk
|
|
#
?
Jun 11, 2015 01:56
|
|
|
Shaggar posted:im writing less stylesheets for each of my knockout components. it sounded good in my head but idk you need to not listen to your head, dude
|
|
#
?
Jun 11, 2015 01:57
|
|
|
Shaggar posted:im writing less stylesheets for each of my knockout components. it sounded good in my head but idk less is good
|
|
#
?
Jun 11, 2015 02:36
|
|
|
Subjunctive posted:you need to not listen to your head, dude uncurable mlady posted:less is good its working so far cause it definitely has made the css more manageable. mixins and variables are own zone. it should make media queries easier too.
|
|
#
?
Jun 11, 2015 02:44
|
|
|
uncurable mlady posted:less is good much like your posting?
|
|
#
?
Jun 11, 2015 03:04
|
|
|
so I have a discussion question for the thread as a terrible programmer, what are some hot tips on how to get your head around a sprawling lovely poorly documented code base? as background, I own a monstrosity of a asp.net mvc application and an associated windows service that is responsible for marshaling integration tests and a whole bunch of other poo poo. it was initially built three or four years ago by some interns and no one who's currently with the company was instrumental in making it (and the people who were there for it weren't involved in making it so there's not a lot of institutional knowledge). I've been trying to burn through the backlog of tickets and also fix + add new stuff where possible, but it's a loving mess. data stuff is split between EF or nhibernate seemingly at random, there's almost no comments (useful or otherwise), there appear to be multiple execution paths to the same outcome depending on what part of the UI you start a task from with no rhyme or reason, and it seems that there's dead code everywhere. other than "attach debugger, set break points, spend a few days stepping through everything" what are some ways to attack the problem?
|
|
#
?
Jun 11, 2015 04:07
|
|
|
setting breakpoints helps. so does reading through commit history. look for medium-sized commits and read through them to figure out why each major piece needed to be changed, even if you don't understand the piece (or change) in detail
|
|
#
?
Jun 11, 2015 04:22
|
|
|
Subjunctive posted:setting breakpoints helps. so does reading through commit history. look for medium-sized commits and read through them to figure out why each major piece needed to be changed, even if you don't understand the piece (or change) in detail yeah, the commit history and the robust test suite should see you through fine
|
|
#
?
Jun 11, 2015 04:27
|
|
|
i'd rewrite it but there is some recommended book that i can't remember the name of: something like "working with legacy codebases" or some poo poo?
|
|
#
?
Jun 11, 2015 04:28
|
|
|
http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 this is the book, good luck
|
|
#
?
Jun 11, 2015 04:29
|
|
|
you don't care about the commit messages, they're going to be useless. you care about which pieces need to be changed at the same time, because that's what tells you the constraints and interactions of the system. if there isn't version control then bribe someone in ops to lose a backup tranche and start a fire
|
|
#
?
Jun 11, 2015 04:30
|
|
|
half the people on my team don't even type in commit messages
|
|
#
?
Jun 11, 2015 04:31
|
|
|
those aren't people, they're meat in clothes
|
|
#
?
Jun 11, 2015 04:33
|
|
|
uncurable mlady posted:so I have a discussion question for the thread look at the database + schema. it's where all the important stuff is but i dont envy you. in a related note, my last company had a rails app with over 1000 models. like literally 1000 tables for a single web application. i checked out the code of the new thing i'll working on here and it's like 20 models. such a good decision.
|
|
#
?
Jun 11, 2015 04:39
|
|
|
Luigi Thirty posted:this place is notorious for lowballing in general but my lowball is in line with the other lowballs according to glassdoor. [e: for Reasons] I also live in my parents' basement and save thousands every month. glassdoor skews crazy low because only complainers provide the data
|
|
#
?
Jun 11, 2015 04:41
|
|
|
Subjunctive posted:you solve that by firing people who are bad, though, not anchoring someone's salary in a bad spot. IMO! why is it that tech employers invert the ancient adage, "a clam in the hand is worth two in the sea" significant raises are impossible to secure, but being willing to negotiate competitive wages for new hires is an industry norm
|
|
#
?
Jun 11, 2015 04:42
|
|
|
Notorious b.s.d. posted:why is it that tech employers invert the ancient adage, "a clam in the hand is worth two in the sea" yeah it's pretty weird
|
|
#
?
Jun 11, 2015 04:49
|
|
|
MALE SHOEGAZE posted:look at the database + schema. it's where all the important stuff is the db and schema are mostly dumpster fires and need to be normalized re: rewrite that's probably ideal, and it's something that theoretically could be done if (and this is the biggest if) I could determine what parts of the application are important. I guess I could try static code analysis and try and see what's actually getting called. alternately I could just rewrite it and patch in functionality later as people scream but I feel like that's why it's in the situation it's in
|
|
#
?
Jun 11, 2015 04:54
|
|
|
Notorious b.s.d. posted:why is it that tech employers invert the ancient adage, "a clam in the hand is worth two in the sea" because the disruption cost to the employee of changing jobs is high, so it's effectively a discount against a different job. also, most employers play a really really short term game. most of the stuff FB does as an employer should really be table stakes, but, because so many companies are so bad at everything related to recruiting and retention, we have our pick of talent because we aren't malicious idiots
|
|
#
?
Jun 11, 2015 04:55
|
|
|
uncurable mlady posted:the db and schema are mostly dumpster fires and need to be normalized like i'm surprised you're really in a position to make the call imo if no one is telling you how to deal with it, just rewrite it
|
|
#
?
Jun 11, 2015 04:56
|
|
|
uncurable mlady posted:the db and schema are mostly dumpster fires and need to be normalized you could try writing tests for it, if the code isn't totally test-hostile. if nothing else you'll have a backstop when you rewrite
|
|
#
?
Jun 11, 2015 04:57
|
|
|
Subjunctive posted:because the disruption cost to the employee of changing jobs is high, so it's effectively a discount against a different job. i have a really hard time with the idea that facebook is like, not awful to work for
|
|
#
?
Jun 11, 2015 05:00
|
|
|
MALE SHOEGAZE posted:i have a really hard time with the idea that facebook is like, not awful to work for come visit
|
|
#
?
Jun 11, 2015 05:02
|
|
|
MALE SHOEGAZE posted:like i'm surprised you're really in a position to make the call my job title, my bosses conception of my job title, my coworkers conception of my job title, and what my job actually consists of bear little relation to each other this is probably why I am the fourth person in a year to have this job title; everyone else breaks within 3-6 months and bails to a more functional part of the company or gets a new job
|
|
#
?
Jun 11, 2015 05:03
|
|
|
uncurable mlady posted:my job title, my bosses conception of my job title, my coworkers conception of my job title, and what my job actually consists of bear little relation to each other are you the ceo?
|
|
#
?
Jun 11, 2015 05:03
|
|
|
megacorps are kind of a tossup between super pleasant to work for or utter trash (microsoft vs amazon) startups are universally terrible tho
|
|
#
?
Jun 11, 2015 05:04
|
|
|
Subjunctive posted:come visit my contract is up in 6 months so maybe then!!
|
|
#
?
Jun 11, 2015 05:08
|
|
|
MALE SHOEGAZE posted:my contract is up in 6 months so maybe then!! if your contract is up in 6 months you should be looking now
|
|
#
?
Jun 11, 2015 05:09
|
|
|
|
| # ? May 23, 2024 18:04 |
|
|
Subjunctive posted:are you the ceo? no, he's much more attractive than I am
|
|
#
?
Jun 11, 2015 05:09
|
|