tag:blogger.com,1999:blog-1777990983847811806.post1849222442683235620..comments2024-03-16T16:29:29.582-07:00Comments on Haskell for all: Worst practices are viral for the wrong reasonsGabriella Gonzalezhttp://www.blogger.com/profile/01917800488530923694noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-1777990983847811806.post-37761087188606075462022-01-28T08:57:14.786-08:002022-01-28T08:57:14.786-08:00My experience is a bit different. When you find a ...My experience is a bit different. When you find a bug, and point it to your teammate, and you show him how to fix it. He goes to HR, and tells them you are mean to him. HR tells you to back off, and to never do it again. <br /><br />Generally, if you will find yourself in a company with a long running project, and this project is a total mess, and you have people who work and develop that for several years, and that mess is really not so hard to fix. Just shut up and find a different company. This code is a mess for a reason, and the reason are those people. They believe they work there for so long because of that mess.<br />When you show that you, alone, can do something, what 2 persons are doing for 5 months, you will be pushed out of the company. Management wont help you either. If they see, you are better organised as them - you're out. You're too much of a danger to their happy lives. Also, you make them(management) look stupid. <br /><br />You wont be hired to a company, unless you believe and do, what other people in that company do. You might create perfect solutions, perfect code, you might be coding super fast, make bug free code - it doesn't matter. They will either see you as a total nutjob or be scared of you. I worked for 18 years now, as a dev (but also i did architecture, networks, infrastructure, front, back, sometimes all of that at the same time), I know that, I still have areas I don't know well, but to be good, I would say, you need around 10 to 15 years of experience, different experience. Most people in management in IT spent only 3, 5 years as devs. People like that, will believe they know how to create software. I don't apply to companies run by 30year olds that quickly skipped devs and went to management - it's not worth my time, interview alone.<br /><br />I'm going tomorrow on a test day for a postman. I will have stable working hours, vacation bonus, christmass bonus(quite big), every year I will get a rise. They have unions. On start they will pay me more than a junior dev gets. It's clear what i have to do, and my bosses are people who have years of experience as a postman. I'm also doing a forklift license(it's freaking good pay, and there is a lot of openings in every bigger city/port).<br /><br /><br /> Krishttps://www.blogger.com/profile/17036886105075789194noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-88805279293635990852014-05-31T20:23:00.398-07:002014-05-31T20:23:00.398-07:00I never get the complaint about "this softwar...I never get the complaint about "this software is not maintained." So? Does it have any bugs? cat(1) hasn't changed much in 20 years. Should I suddenly stop using it?<br /><br />Knuth did this right with TeX. Stabilize the core and leave it alone.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-30744869905045140992014-04-22T08:22:20.071-07:002014-04-22T08:22:20.071-07:00There is an easy fix: deploy a file: days-without-...There is an easy fix: deploy a file: days-without-bugs-reported.txt and have the counter inside increment by some autoupdater each day. This makes you have daily commits without actual work involved. Now you only need to reset the counter once a bug was found ;)noamikhttps://www.blogger.com/profile/01782107405101545600noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-31306244231100143232014-04-21T07:28:47.438-07:002014-04-21T07:28:47.438-07:00Yeah, I exaggerated just to make a point. My outl...Yeah, I exaggerated just to make a point. My outlook is not that pessimistic. :)Gabriella Gonzalezhttps://www.blogger.com/profile/01917800488530923694noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-37836487087474998372014-04-21T04:49:53.797-07:002014-04-21T04:49:53.797-07:00* The software community has a great environment o...* The software community has a great environment of knowledge sharing through user groups, conferences and such. Instead of going into academia, you could use this, give talks about doing things the right way. This should give you some regards, i.e. leverage that can be used to argue against bad practices. Would at least help with getting a new task after making oneself obsolete at the current one.<br /><br />* successful projects can on occasion be detected by the management. If the whole team then states that they 'well, just did the right thing', people might take note. Could be a tad hopeful, this, but there are companies around where this actually works. Probably depends on company size.<br /><br />* there'll always be a desire for more features. If you did things right (low coupling, open architecture etc), implementing these probably isn't hard, even if they make things stand on their head. This should make people want to have you around for the next feature, even if you're kind of obsolete in between. <br /><br />Just some random thoughts to try a more positive angle, though I share your opinion at least halfway through ;-) Would like to see a follow-up that puts framework hype into that picture, too...Thorsten Krügerhttps://www.blogger.com/profile/12337156618456657864noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-6488442805192535772014-04-19T11:00:39.411-07:002014-04-19T11:00:39.411-07:00Ohloh for example illustrates the problem you'...Ohloh for example illustrates the problem you're describing quite well on the open source front. I, for example, wrote a bunch of very basic libraries which provide their functions well and are tested. By design, they shouldn't take up a lot of memory, so they shouldn't be extended inside the same source base. So essentially, the code is stable and will not be changed unless I find a bug (which I haven't so far).<br /><br />On Ohloh, the libraries have a big warning sign in front of their names saying «This project appears to be abandoned, there were no commits in the last 6 years». Sure, because why would there be? The code does exactly what it should, and not more and not less. I use the code every day.<br /><br />Now that's just Ohloh, but many developers work that way as well. They look at the source tree and see «Eww, the last commit is from 2008! The last release tarball as well! Clearly, this project is dead.» It's not, it's just working.<br /><br />That's why there's a tendency for Open Source developers to reinvent the wheel over and over again, unless the project has feature creep, which makes it relevant forever by those metrics.Anonymoushttps://www.blogger.com/profile/14912034200573624733noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-58693409912424840222014-04-19T05:47:48.124-07:002014-04-19T05:47:48.124-07:00“More employees reporting to you increases your ch...“More employees reporting to you increases your chances of promotion”<br /><br />That is complete nonsense.<br /><br />“You can make a compelling case to management that your team needs more head count to continue supporting this feature.”<br /><br />Even that is borderline ridiculous.<br /><br />“Your code requires little maintenance, so little in fact that your team is now obsolete.”<br /><br />Wat? Have you ever actually been in such a team? (No you haven’t.)<br />You completely and deliberately left out that they will have much more money as a result of the success and as a result of… let’s say it that way: A boss wants to keep his job too, so he finds a new project for them to make even more money and brag about it and hire /even more/ people!<br /><br />Also: As if anyone would deliberately let his boss know that he has too little to do… lol. If anything, given that they are skilled, they’d probably present some cool project of their own to their boss who would then use that to make more money and brag and get more employees.<br /><br />Google is the best example: Barely anyone there is really essential. By your sorry attempt at logic they’d all be fired.<br />Except in actual reality that’s not what happens, *now is it*??<br /><br />Sorry, a couple of hand-crafted made-up scenarios are not a valid basis for an argument.<br /><br />"… unless they go into academia."<br /><br />Aaah, now I get where all this is coming from. It’s an inferiority complex and you need something to make you feel superior. So you argue about something you have no competence in, to… conveniently… conclude that your is better.<br /><br />Silly. There was nothing wrong with academia in the first place. There’s probably nothing wrong with you either. You just have the stigma of intelligent people, that we are so good at seeing all the ways we could be wrong, that mechanisms emerge to blind oneself for the sake of one’s own sanity.<br /><br />Everything is OK with you. You don’t need to put this distortion filter between you and reality. Reality is OK.BLOGGER IS A CRIMINAL ORGANIZATIONhttps://www.blogger.com/profile/15647496338237199638noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-87991887162849132142014-04-14T15:39:24.583-07:002014-04-14T15:39:24.583-07:00I'm not sold on this idea. I think it's mo...I'm not sold on this idea. I think it's more because best practice are fundamentally non intuitive. The typical example is: 'adding more people to a late project will make it ship even later', or the whole testing thing (this takes time and effort to design with testing in mind and testing is time consuming yada yada).<br /><br />What you're stating is the corollary of this: worst practice are just 'what everyone does naturally'Unknownhttps://www.blogger.com/profile/02473352501311593203noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-43539267611955081232014-04-10T14:29:50.482-07:002014-04-10T14:29:50.482-07:00Had similar thoughts for a while. You've summe...Had similar thoughts for a while. You've summed it up pretty well.Anonymoushttps://www.blogger.com/profile/01392841384115980156noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-75400513256248513432014-04-04T21:50:02.151-07:002014-04-04T21:50:02.151-07:00At the same time, that's a nifty feature of hu...At the same time, that's a nifty feature of humanity sometimes: finding the clever "hack" that confers a huge advantage. In some ways, humans are a reflection of their environment: inelegant and circumstantial on small scales yet modular at larger scales.Gabriella Gonzalezhttps://www.blogger.com/profile/01917800488530923694noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-32988249818980451312014-04-04T21:44:49.915-07:002014-04-04T21:44:49.915-07:00Yeah, I believe good programmers can and should ma...Yeah, I believe good programmers can and should make themselves obsolete. A friend of mine warned me away from going into consulting exactly for that reason: consultants have an even larger incentive to delay solving the problem.Gabriella Gonzalezhttps://www.blogger.com/profile/01917800488530923694noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-11439098332008646142014-04-04T21:39:02.921-07:002014-04-04T21:39:02.921-07:00Ha! I still enjoy programming, don't worry. ...Ha! I still enjoy programming, don't worry. :)Gabriella Gonzalezhttps://www.blogger.com/profile/01917800488530923694noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-36070619558470381692014-04-04T05:28:37.711-07:002014-04-04T05:28:37.711-07:00And of course there is that "let's pull i...And of course there is that "let's pull it together quickly, and fix the sloppy code later" attitude. Though it seems to be a universal human trait, actually, not restricted to programming.<br /><br />A year ago I watched several lets-plays of Far Cry 3 (about 6 or 7): the game takes place on an island with many mountains and hills, so there are plenty of slopes you can't (but want to) climb. Or you can, but after jumping just in the right direction, from the right place. That's the first premise, the second premise is that there are many, many roads and footpaths, and they lead to literally any place of interest.<br /><br />And that leads to a somewhat hilarious observation: all seven lets-players CONSTANTLY found themselves trying to climb a particularly uncooperative elevation, and after a minute or so they succeed—only to find that there is a road up there that is coming from exactly the place they were trying to climb, so it would be quicker to just walk around by that road.<br /><br />And none of them seem to even notice that, mind you! I personally tried to play the game trying to stick to the roads as much as possible—and it worked ridiculously well, never had to leave them for anything including escaping from the chase. But that required a certain sort of self-discipline, to suppress "oh, I could shorten the path if I would climb that" urges.<br /><br />Given the game itself defines insanity as "repeating the same thing over and over and over and over, hoping that *this* time it will be different", I conclude that we're all mad. Or we wouldn't have come here, right?Joker_vDhttps://www.blogger.com/profile/15515260210737317416noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-31341550468604441292014-04-01T12:42:04.740-07:002014-04-01T12:42:04.740-07:00In my experience, the software teams that work bes...In my experience, the software teams that work best are the ones with self-driven individuals who share the common goal of releasing high quality code. In this cases management is almost unnecessary, they can help with communication and shielding from bureaucracy, customers, etc.<br /><br />The problem in many companies being a manager is seen as the equivalent to being the "boss" and programmers are seen as disposable pawns that just sit there toying around with nerdy machines. These managers have to be proving continuously, often clumsily, who is in charge. I guess that's the basis for Dilbert's cartoons.<br /><br />Getting rid of these managers, is out of question most of the times, as they are frequently, somehow, involved in bringing the money for the project.<br /><br />No wonder why the most successful software companies are founded by engineers.Dannyhttps://www.blogger.com/profile/17832030446806236723noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-74121013925387964102014-04-01T08:04:25.026-07:002014-04-01T08:04:25.026-07:001 - I have seen this myself in over 37 years of pr...1 - I have seen this myself in over 37 years of programming.<br />2 - Isn't this similar to the position faced by medical doctors and probably some other professions - i.e. a good doctor gets you well, then you don't need him any more. A bad doctor keeps you sick, and so he is needed more. Perhaps it is just a professional hazard?<br />bcbarneshttps://www.blogger.com/profile/08082143120762541106noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-79585332018841338042014-04-01T07:25:48.905-07:002014-04-01T07:25:48.905-07:00Aren't you a bit young to that jaded! ;-) (...Aren't you a bit young to that jaded! ;-) (and most likely accurate!)haroldcarrhttps://www.blogger.com/profile/09763473450957698221noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-33053880671384491172014-04-01T06:53:26.048-07:002014-04-01T06:53:26.048-07:00I think your last sentence answers your first sent...I think your last sentence answers your first sentence. :)<br /><br />More seriously, I agree with you. I just think people who advocate correctness just need to be a little more proactive.Gabriella Gonzalezhttps://www.blogger.com/profile/01917800488530923694noreply@blogger.comtag:blogger.com,1999:blog-1777990983847811806.post-47410664971201086912014-04-01T05:33:20.527-07:002014-04-01T05:33:20.527-07:00How about teams with mixed background? A teammate ...How about teams with mixed background? A teammate writes error-prone code, and inevitably, the code has a bug. I take the bug, track the origin of the bug to the error-prone practice, rewrite it in a simpler way, and show my teammate how my approach prevents this entire category of bugs. True story. Now when that teammate encounters this category of bugs in another project, they spread the gospel! That part of the story hasn't came true yet.gelisamhttps://www.blogger.com/profile/10619127479176568208noreply@blogger.com