|
rt4 posted:The worst part about being in a SVN workplace is that you can't convince them to adopt git and branching because they all think branching is too difficult after years of using SVN. What's so hard about SVN and branching for every story? Not as lightweight as git but seems workable.
|
#
?
Jul 24, 2016 15:55
|
|
|
|
| # ? May 9, 2024 22:56 |
|
|
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
|
|
|
smackfu posted:What's so hard about SVN and branching for every story? Not as lightweight as git but seems workable. Merging is a huge loving pain. If the dumb metadata files that svn shits all over your codebase (for merging purposes I think) are just SLIGHTLY messed up, all your merges are probably gonna get super hosed up. Those metadata files I think are corruptible by SVN itself w/o anyone explicitly loving w/ them. At least that's seemingly what happened to me when I tried branching! I got so frustrated I checked the SVN branch and main development into GIT and did the merge that way and it was a lot better. When that happens, you question why are you even using SVN...
|
|
#
?
Jul 24, 2016 20:02
|
|
|
comedyblissoption posted:I got so frustrated I checked the SVN branch and main development into GIT and did the merge that way and it was a lot better. When that happens, you question why are you even using SVN... Because there's at least one old fart that says that git is too complex (meaning that they don't understand git) to implement. And that assuming that they know that git exists.
|
|
#
?
Jul 24, 2016 20:12
|
|
|
Man, I just took off 3 weeks PTO and the first day I was back I was already goofing off in the forums quite a bit. Is this burn out already?
|
|
#
?
Jul 26, 2016 03:25
|
|
|
HardDisk posted:Man, I just took off 3 weeks PTO and the first day I was back I was already goofing off in the forums quite a bit. Is this burn out already? Sounds like a good Monday to me.
|
|
#
?
Jul 26, 2016 03:41
|
|
|
Don't get me wrong, I love to goof off, especially on Mondays. And I don't mind being not excited about my job, but I would have liked to be excited enough to come home and put some of my ideas for projects in practice. As it is, I literally come home home, sigh and just proceed to jerk off the rest of the evening.
|
|
#
?
Jul 26, 2016 03:53
|
|
|
HardDisk posted:Don't get me wrong, I love to goof off, especially on Mondays. And I don't mind being not excited about my job, but I would have liked to be excited enough to come home and put some of my ideas for projects in practice. As it is, I literally come home home, sigh and just proceed to jerk off the rest of the evening. Look man, don't be upset that you don't feel like coming home and coding for 6 more hours after coding all day at your job. By the time I'm done at work my brains are usually leaking out my ears and I simply don't have the mental energy left for any more programming, despite having things I'd like to make. More importantly, I'm certain that if I forced myself to do it anyway, I would burn out extremely rapidly, and my personal projects would probably be mostly poo poo code anyway. It even applies to the end of the day at work. One of the best things I've done to improve my own code quality is learn to recognize when I'm running out of gas and stop before I commit something that's going to shatter the world if it goes live. If that means I stop coding after 6 hours, so be it (I usually have more than that, just sayin). As for your vacation, it usually takes me a bit longer after a vacation to spin back up than it does after a weekend.
|
|
#
?
Jul 26, 2016 04:16
|
|
|
I usually goof off about an hour per day, there have been a lot of studies that show after 35 hours your productivity goes to poo poo.
|
|
#
?
Jul 26, 2016 04:35
|
|
|
I usually spend maybe 10% of my day actually coding, 30% thinking, 10% doing code reviews/other procedural stuff and a good half just daydreaming/goofing off because gently caress trying that hard all day, I only have so much mental energy to spend and it needs time to recharge. Sometimes we have hackathons where they stay until 2am or something and I don't understand how people manage this without having their brains dribble out of their ears.
|
|
#
?
Jul 26, 2016 04:40
|
|
|
But because most business owners don't care about worker productivity as much as output, almost everyone will take the integral of the productivity curve and only ask you to stop once productivity is 0. And because exempt workers officially only count as 40 hours, "productivity" goes up. The exceptions are basically government and the actually decent places to work that miraculously stay in business despite horrific rear end in a top hat competitors that make Hitler and Stalin look like hippies.
|
|
#
?
Jul 26, 2016 04:43
|
|
|
necrobobsledder posted:But because most business owners don't care about worker productivity as much as output, almost everyone will take the integral of the productivity curve and only ask you to stop once productivity is 0. And because exempt workers officially only count as 40 hours, "productivity" goes up. The exceptions are basically government and the actually decent places to work that miraculously stay in business despite horrific rear end in a top hat competitors that make Hitler and Stalin look like hippies. Productivity only goes up if nobody checks in garbage near the end of the day that takes hours to remember and hunt down and undo, or that gets through your lax or nonexistent QA process and goes live. It's not just that business owners don't care, they don't realize (or believe in) the above scenarios. That's because business owners by and large think of us as factory workers making widgets, and if they can get us to push button A and pull lever C 20% more times during they day, they'll get 20% more widgets. For FREE! Also intangibles like morale and risk and retention require actual thought to estimate their value, so the idiot managers will fall back on the obvious, like TIME_SPENT_IN_CHAIR. I'm lucky in that my boss is pretty good about not doing that, and the freedom is something I'll be loathe to give up in future jobs.
|
|
#
?
Jul 26, 2016 05:55
|
|
|
In the early twentieth century there were lots of industrial studies done on what is the optimal work week and businessmen discovered that working your employees to death was counterproductive and that optimal productivity for the mean worker converged around 40 hours or thereabouts. Henry Ford was cajoled by his peers for reducing the work week of his workers based on empirical evidence and was cited as a threat to industry. The industry as a whole probably came around to the idea that working your workers to death is counterproductive. These labor studies were done on labor that was far more menial than software development. Businessmen and management in software are basically incredibly and willfully ignorant of these facts so that they can satisfy their childish and non-empirical notions of productivity and puritan work ethic. It also sometimes sets up an abusive and exploitive work relationship i guess. I think there are definitely people that can still maintain productivity well above 40 hours, but those are not mean mortals. comedyblissoption fucked around with this message at 13:47 on Jul 26, 2016 |
|
#
?
Jul 26, 2016 13:45
|
|
|
Che Delilas posted:It's not just that business owners don't care, they don't realize (or believe in) the above scenarios. That's because business owners by and large think of us as factory workers making widgets, and if they can get us to push button A and pull lever C 20% more times during they day, they'll get 20% more widgets. For FREE! Much of the harmful business thinking methodologies and approaches literally are to try to make knowledge and creative workers more like manufacturing because most of the 20th century's business practice was about America as a manufacturing superpower, and that's how most generations learned to manage via Taylorist management practices - worship of management as a knowledge and job allocation center that appealed to capitalist, selfish egos. Thankfully, we had alternative approaches like from W. Edwards Deming whom, spurned by much of American leaders, went to Toyota who accepted his ideas on quality and a much more dynamic workforce, and most software and technology organizations today will not be successful in any form of innovation without using his approaches. Truth is that most of the US business world is still stuck in a manufacturing mindset and as long as their efforts are rewarded with continued revenue and funding, that's a positive feedback loop. No wonder that American businesses shipped labor overseas - they are designed to retain only obedient, cheap slaves with a ruling management caste while pushing out creative people that want to change things frequently. The culture does not value high capability creative persons - our culture says that the really smart, productive creative person should start a company that replicates that output at industrialized scale, and the managers should be the only ones that really matter. Workers are treated like machines - measured, goals set, trained for specific tasks, etc.
|
|
#
?
Jul 26, 2016 14:05
|
|
|
necrobobsledder posted:I don't quite feel that they don't know - I read through all sorts of this stuff in a random HBR series of courses that lots of companies sign employees up for, doubt you won't see it in an MBA program. The problems are better explained in Leadership BS. Thanks for this post. I'm going to check out that book.
|
|
#
?
Jul 26, 2016 14:36
|
|
|
Che Delilas posted:Look man, don't be upset that you don't feel like coming home and coding for 6 more hours after coding all day at your job. By the time I'm done at work my brains are usually leaking out my ears and I simply don't have the mental energy left for any more programming, despite having things I'd like to make. More importantly, I'm certain that if I forced myself to do it anyway, I would burn out extremely rapidly, and my personal projects would probably be mostly poo poo code anyway. Yeah, that makes sense, thanks. I still can't imagine how some people have the energy to both code at work and then work on OSS or personal projects in their free time.
|
|
#
?
Jul 26, 2016 15:21
|
|
|
HardDisk posted:Yeah, that makes sense, thanks. I still can't imagine how some people have the energy to both code at work and then work on OSS or personal projects in their free time. I find this is usually easier for people who aren't over committed at their job or have lull periods. It really can depend on the team you working on if this is possible. Usually, if I take a week away from vacation I might start trying to write something, but I have to make it so small and trivial so that I finish it before I come back to work. Otherwise, it will just depress me that I haven't worked on it in 5 months.
|
|
#
?
Jul 26, 2016 15:45
|
|
|
HardDisk posted:Yeah, that makes sense, thanks. I still can't imagine how some people have the energy to both code at work and then work on OSS or personal projects in their free time. compuserved posted:Thanks for this post. I'm going to check out that book.
|
|
#
?
Jul 26, 2016 15:55
|
|
|
comedyblissoption posted:I think there are definitely people that can still maintain productivity well above 40 hours, but those are not mean mortals. The ones I've met have not been nice mortals.
|
|
#
?
Jul 26, 2016 17:36
|
|
|
No programmer can produce quantity with quality for all 40+ hours a week unless the work is trivial and has been done many times before. If you don't stop and think about your approach in advance, you will probably have to refactor a few times, and the quality throughout won't be as high as if you had just spent a few hours thinking about it in advance before you started. I found I was significantly more productive when I was time constrained on my side project to like 60-90 minutes a night but I was able to think about what I wanted to accomplish in that time for a few hours. I probably got more done, and the quality was better than if I had just ground out 8 hours on it without any thought.
|
|
#
?
Jul 26, 2016 18:03
|
|
|
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
|
|
|
This is 100% all the MBA's fault. I do the maths that make the moneys go to me  Also gently caress you if you aren't working 24/7/100% you lazy fucker you're fired.
|
|
#
?
Jul 27, 2016 02:06
|
|
|
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
|
|
|
if theyre savvy/lucky they'll get promoted or receive a windfall before the consequences of their decisions can be realized
|
|
#
?
Jul 27, 2016 04:38
|
|
|
Why pay 5 good programmers 60k a year each when you can hire 20 dudes in India for 15k each? Four times as many people means it gets done four times as fast and you save money, right?!
|
|
#
?
Jul 27, 2016 05:15
|
|
|
If you're a good developer and making 60k please find another job
|
|
#
?
Jul 27, 2016 10:50
|
|
|
Fine. Moderately competent developers.
|
|
#
?
Jul 27, 2016 10:51
|
|
|
If you're a moderately competent developer and you make 60k, please move to America instead of whatever backwater third world you currently inhabit.
|
|
#
?
Jul 27, 2016 13:53
|
|
|
Plenty of moderately competent developers living in flyover country making 60k... as junior developers.
|
|
#
?
Jul 27, 2016 14:32
|
|
|
necrobobsledder posted:Plenty of moderately competent developers living in flyover country making 60k... as junior developers. Plenty of people habitually undersell themselves too!
|
|
#
?
Jul 27, 2016 15:13
|
|
|
Are there any good resources out there regarding refactoring poorly written (ie. hacked together by EE's who resisted hiring developers for a decade because "lol programming is easy") code or strategies for deciphering the most inane and incoherent business logic possible? I got an amazing offer to rebuild a business application, good pay, remote work 4/5 days a week. The project itself though, I'm not sure how to approach it without literally asking the guy who wrote this mess to just sit next to me all day and explain why Contains("Tf") means good and Contains("TG") || Contains("56") && Contains("LOL") means bad. There are like 50 classes of this that need to be refactored.
|
|
#
?
Jul 27, 2016 15:56
|
|
|
Portland Sucks posted:Are there any good resources out there regarding refactoring poorly written (ie. hacked together by EE's who resisted hiring developers for a decade because "lol programming is easy") code or strategies for deciphering the most inane and incoherent business logic possible? I got an amazing offer to rebuild a business application, good pay, remote work 4/5 days a week. The project itself though, I'm not sure how to approach it without literally asking the guy who wrote this mess to just sit next to me all day and explain why Contains("Tf") means good and Contains("TG") || Contains("56") && Contains("LOL") means bad. There are like 50 classes of this that need to be refactored. Start with the actual requirements and re-build from scratch?
|
|
#
?
Jul 27, 2016 16:29
|
|
|
Portland Sucks posted:Are there any good resources out there regarding refactoring poorly written (ie. hacked together by EE's who resisted hiring developers for a decade because "lol programming is easy") code or strategies for deciphering the most inane and incoherent business logic possible? I have heard good things about Working Effectively with Legacy Code.
|
|
#
?
Jul 27, 2016 19:57
|
|
|
Slash posted:Start with the actual requirements and re-build from scratch?
|
|
#
?
Jul 27, 2016 21:20
|
|
|
Slash posted:actual requirements lmbo
|
|
#
?
Jul 27, 2016 21:22
|
|
|
Portland Sucks posted:Are there any good resources out there regarding refactoring poorly written (ie. hacked together by EE's who resisted hiring developers for a decade because "lol programming is easy") code or strategies for deciphering the most inane and incoherent business logic possible? I got an amazing offer to rebuild a business application, good pay, remote work 4/5 days a week. The project itself though, I'm not sure how to approach it without literally asking the guy who wrote this mess to just sit next to me all day and explain why Contains("Tf") means good and Contains("TG") || Contains("56") && Contains("LOL") means bad. There are like 50 classes of this that need to be refactored. Somebody already posted the book, so I'll just post some anecdotes from having to do literally the same thing--refactor lovely EE code--for a living: 1. Get all that stuff in good source control. I say it because EE trash heaps usually aren't, so I assume nothing. Being able to easily create throwaway branches in git will make it less intimidating to mess with it. 2. Also start to get some unit and integration tests in there so you can start to reign in the whack-a-mole game you'll inevitably play. 3. Encapsulate the globals before you try to deal with any objects that are in there. The data flow problem of getting that global state passed around will drive most of your refactoring decisions. 4. It will probably also help to review and revise the entire source layout of the project. 5. If there was any prior source control, try to get all the binaries out of it. I had a 16GB subversion project inflate to 48+GB when migrated to git, and then collapsed to 20MB after rewriting out all the binaries in the history. 6. Consider added a usage statistics agent for marking code paths that actually aren't dead. You might be afraid to flatten some code because something might use it, but you don't have proof. So put a phone-home call in there that goes somewhere that you can find a report of it. Put another line in the normal path. If after some time in the next release, you see the normal path but not the dead path, then you can assume the risk of killing the dead stuff. If you get no usage information, you know that mechanism is not working. 7. The good news is that most of the refactoring is collapsing ten-page-long if/else clauses that have 95% of the same code in them. 8. When people give you poo poo about it, tell them you're "adding functionality by removing code." 9. Rest assured that any incomprehensible math you see was probably done either from iterative guessing and/or poor notions of premature optimization, and listen to the voice in your head. At the least, you can encapsulate the mathematical model and write unit tests against it to verify that a revised model computes the same. 10. If you are second-guessing why they didn't use a function/method native to whatever language they're using, it's because that isn't native to the basic C code they learned in that one semester of C crap they might have gotten in college. They just didn't know about it and it's probably safe to use the library. 11. There's also a good chance that the parts that are very EE-centric and out of your domain of expertise are also poo poo and you shouldn't second-guess yourself with them. Good EE's are fully capable of writing clean code. It took me years to figure out most of the EEs I was working with couldn't even do core EE stuff. Meanwhile, the ones that could write this stuff cleanly are now your best friends at work. So don't paint with a broad brush--like I just did. 12. Watch out for version 2.0 syndrome after you comprehend the code base and know enough to blow it all up and start over. The 2.0 may end up taking far too long and discredit you.
|
|
#
?
Jul 27, 2016 22:45
|
|
|
Painstakingly refactoring such a mess and rebuilding it from scratch are both terrible ideas. The only question is which is the least terrible option.
|
|
#
?
Jul 28, 2016 07:27
|
|
|
Rocko Bonaparte posted:Somebody already posted the book, so I'll just post some anecdotes from having to do literally the same thing--refactor lovely EE code--for a living: This is all excellent advice. I have inhereted several messes, and not once has "rebuilding it from scratch" worked. In addition to doing what he said above, I also have started doing this: 1) Start writing unit tests for EVERYTHING, I mean it, EVER SINGLE THING you can find. 2) Start refactoring code little by little. Eventually it will start to look good. 3) Get a automated test server. I like gitlab runner personally, and use it all the time.
|
|
#
?
Jul 28, 2016 17:32
|
|
|
If it's actually embedded systems stuff, testing your code may be basically impossible without a physical test harness, but comments for failure modes are helpful for whoever inherits the codebase next. Non-software engineers seem to have a habit of never, ever documenting anything for someone else that doesn't already know the domain inside-out. I had a breadboard setup before and logic analyzers and to document the hardware-level error cases I had a mapping where if a unit test failed on bit patterns it'd spit back which ones failed and attempted to guess which wires were glitchy on the board. The idea was that some intern was going to get the project to hack on eventually and they don't have time to play whack-a-wire.
|
|
#
?
Jul 28, 2016 18:53
|
|
|
|
| # ? May 9, 2024 22:56 |
|
|
I spent an entire day trying to figure out why a script I made for customer service for a huge order wasn't working. I had smashed a )) instead of ) into a config file. 
|
|
#
?
Jul 28, 2016 21:33
|
|