Catfish Programmers(butternotes.com)
butternotes.com
Catfish Programmers
https://www.butternotes.com/blog/catfish-programmers
176 comments
In rewriting projects, I often find that as I rewrite them, I can knock out requested features along the way. I've taken this approach when fixing up some of my old personal codebases. It's a two birds one stone approach; it takes me just as long to fix code in the old framework as it does to rewrite the code in the new framework without the buggy behavior, so where possible I do that.
We had a similar practice in the restaurant world before I found work as a programmer, and we called it "clean as you go." I think it's quite appropriate. The bug reports will always be there, the feature requests mountainous, and yet the messes don't clean themselves. There must be balance.
Do what needs to be done, but make a point to improve your codebase with every new change. Prefer consistency over new hotness, and ease of maintenance over unreadable micro-optimizations. Be a positive force in your codebase, and future developers, especially including yourself, will appreciate your efforts.
We had a similar practice in the restaurant world before I found work as a programmer, and we called it "clean as you go." I think it's quite appropriate. The bug reports will always be there, the feature requests mountainous, and yet the messes don't clean themselves. There must be balance.
Do what needs to be done, but make a point to improve your codebase with every new change. Prefer consistency over new hotness, and ease of maintenance over unreadable micro-optimizations. Be a positive force in your codebase, and future developers, especially including yourself, will appreciate your efforts.
I agree with "clean as you go", but I'm very cautious. Rewrites are scary and risky in legacy code. Usually I'll add a few unit tests to increase coverage and de-risk the change I just made.
Leaving code as is can also be scary and risky. Being asked to overhaul an existing system on day 1 is scary though.
I tend to hold off on rewrites until I can picture the new system - complete with a solid understanding of exactly how it will fix the problems of the old one. And yes, with good tests.
I tend to hold off on rewrites until I can picture the new system - complete with a solid understanding of exactly how it will fix the problems of the old one. And yes, with good tests.
Aye, I agree completely. When approaching a given rewrite, I'm very hesitant to go through with it unless I have a strong understanding of all the files I'm about to have to touch to fix the resulting compiler errors. Ideally this should be straightforward, but the tight coupling often observed in poorly maintained codebases can cause the most innocent of small changes to spiral out into the template metaprogramming circle of death.
Even then though, all is not lost! When faced with an architecture change that really should be made, but is too large to make right now, I make a note of it on a project board somewhere and now I have a new sub-task. Any time I touch code elsewhere, I work to reduce coupling and correct dependency issues, so that the original change is easier to make. By slowly cleaning up small parts of the code, I open the door to making the larger rewrite not quite so large when I get around to it, and hopefully improve the project's overall quality in the process. In this way, I create forward progress towards the end goal without needing to commit to all of it at once.
Even then though, all is not lost! When faced with an architecture change that really should be made, but is too large to make right now, I make a note of it on a project board somewhere and now I have a new sub-task. Any time I touch code elsewhere, I work to reduce coupling and correct dependency issues, so that the original change is easier to make. By slowly cleaning up small parts of the code, I open the door to making the larger rewrite not quite so large when I get around to it, and hopefully improve the project's overall quality in the process. In this way, I create forward progress towards the end goal without needing to commit to all of it at once.
I think this epic rant against rewrites still is mostly valid 17 years later:
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
It was wrong then and it is still wrong.
First of all Netscape had the problem of incorporating opaque blobs from other sources. When they went open source, they couldn't keep those so ripped them out. Then the code didn't even compile.
Secondly that Netscape release that he mocked? That was the start of Mozilla, Firefox, and so on.
Third, how did Netscape survive? My impression from the sidelines is that it was a negotiation ploy from AOL. When their IE contract was up, they needed a viable alternative. In the end Microsoft let them continue using IE, PAID THEM MONEY, and had them shut down Netscape. They were laughing about this all of the way to the bank. And then Mozilla ate IE's lunch.
There have been a lot of rewrites. Some succeed, some fail. But it isn't always a bad idea to do one. And Netscape was a necessary one that succeeded in every measure that it was supposed to.
First of all Netscape had the problem of incorporating opaque blobs from other sources. When they went open source, they couldn't keep those so ripped them out. Then the code didn't even compile.
Secondly that Netscape release that he mocked? That was the start of Mozilla, Firefox, and so on.
Third, how did Netscape survive? My impression from the sidelines is that it was a negotiation ploy from AOL. When their IE contract was up, they needed a viable alternative. In the end Microsoft let them continue using IE, PAID THEM MONEY, and had them shut down Netscape. They were laughing about this all of the way to the bank. And then Mozilla ate IE's lunch.
There have been a lot of rewrites. Some succeed, some fail. But it isn't always a bad idea to do one. And Netscape was a necessary one that succeeded in every measure that it was supposed to.
You are being charitable to Mozilla (the application suite). That was a bloated, buggy mess for years. I recall 2001-2003 was a really bleak time to be a Mozilla user. Firefox launched as a response to Mozilla and was more lean, but it wasn't until 2007 or 2008 that HTML5 features started trickling in and Firefox started to gain marketshare and developer mindshare for the advanced features it could offer.
And that was when Chrome showed up. So from 1998-2008, Mozilla had an open season to gain ground on IE, and their marketshare only ever got as high as 30%. It was 2011 or 2012 that Chrome was stable enough and Google started their upgrade-to-Chrome adverts on google.com. And then Firefox faded back into it's 10% niche. I'm a developer, and my peers look at me like I'm a weirdo because I favor Firefox and do my primary development on it. That shouldn't have happened, Firefox should not be niche given the time they had to work.
It is inspiring to me that the Mozilla project didn't fail and got so much love, but starting with that original Netscape codebase and the Gecko and XPCOM designs really hindered them. Mozilla missed out on offering a competing engine for Node.JS because their JS engine is so tightly coupled with the rest of the browser(?) - that's just one huge opportunity missed. Offering a competitive mobile OS at the advent of smartphones in the vein of WebOS is another, albeit less egregious, miss. The codebase just wasn't clean nor adaptable enough to break free of the desktop.
And that was when Chrome showed up. So from 1998-2008, Mozilla had an open season to gain ground on IE, and their marketshare only ever got as high as 30%. It was 2011 or 2012 that Chrome was stable enough and Google started their upgrade-to-Chrome adverts on google.com. And then Firefox faded back into it's 10% niche. I'm a developer, and my peers look at me like I'm a weirdo because I favor Firefox and do my primary development on it. That shouldn't have happened, Firefox should not be niche given the time they had to work.
It is inspiring to me that the Mozilla project didn't fail and got so much love, but starting with that original Netscape codebase and the Gecko and XPCOM designs really hindered them. Mozilla missed out on offering a competing engine for Node.JS because their JS engine is so tightly coupled with the rest of the browser(?) - that's just one huge opportunity missed. Offering a competitive mobile OS at the advent of smartphones in the vein of WebOS is another, albeit less egregious, miss. The codebase just wasn't clean nor adaptable enough to break free of the desktop.
It wasn't until 2007 that HTML5 features began trickling in anywhere...
Right, and what I was alluding to in that point was, why should any user switch from IE if it has feature parity with Firefox or any other browser?
Firefox had developer tools in Firebug, so it was already getting a geek user base, but when Firefox got some legitimate new features like Canvas that other advanced browsers like Safari had, regular users began to dabble. With the occasional news report that honestly reported the security nightmare that IE was, I found that between 2006-2009, Firefox was an easy sell to regular users.
The way I see history, Mozilla floundered between 1998 and 2005 and had almost no marketshare. All the Netscape rewrites that came before were a shitshow and the AOL thing must have been a huge (but necessary for funding) distraction. Probably the only fair interpretation of history is that, of course, the codebase was a mess given the development practices back in the day.
That said, I recall the Gecko rewrite was a long and painful one. Was it unnecessarily so? I believe it had a lot of dumb component architecture concepts and I would love to understand what the drivers were there. Did they believe that components were the best way to organize a huge open source project? Woulda, coulda, shoulda thinking about Mozilla makes me really sad sometimes.
Firefox had developer tools in Firebug, so it was already getting a geek user base, but when Firefox got some legitimate new features like Canvas that other advanced browsers like Safari had, regular users began to dabble. With the occasional news report that honestly reported the security nightmare that IE was, I found that between 2006-2009, Firefox was an easy sell to regular users.
The way I see history, Mozilla floundered between 1998 and 2005 and had almost no marketshare. All the Netscape rewrites that came before were a shitshow and the AOL thing must have been a huge (but necessary for funding) distraction. Probably the only fair interpretation of history is that, of course, the codebase was a mess given the development practices back in the day.
That said, I recall the Gecko rewrite was a long and painful one. Was it unnecessarily so? I believe it had a lot of dumb component architecture concepts and I would love to understand what the drivers were there. Did they believe that components were the best way to organize a huge open source project? Woulda, coulda, shoulda thinking about Mozilla makes me really sad sometimes.
When Mozilla started, it was not clear that there could ever be a browser that would take marketshare from IE. Common wisdom was that the browser wars for over..for good.
We actually got to the point where 30% of people who bought a computer went and installed a different browser. That's amazing. How many computer users don't have a clear understanding of what a browser is, let alone how to install one?
Before Google blindsided the industry, nobody believed that anyone would ever put anything like the effort that they did into improving JavaScript. I cannot criticize anyone for making decisions that seemed perfectly reasonable at the time but didn't age well.
As for HTML5, there was a chicken and egg problem. When you don't have marketshare, nobody cares about your wonderful features that nobody is using. So you have to get feature compatibility first, then marketshare, and only THEN turn to wishlist items. All that Microsoft needed to do to keep the browser wars won was keep investing in IE. Make it a moving target that nobody can catch up to.
They didn't simply because they had won. Won so completely that they thought that they could rest on their laurels.
We actually got to the point where 30% of people who bought a computer went and installed a different browser. That's amazing. How many computer users don't have a clear understanding of what a browser is, let alone how to install one?
Before Google blindsided the industry, nobody believed that anyone would ever put anything like the effort that they did into improving JavaScript. I cannot criticize anyone for making decisions that seemed perfectly reasonable at the time but didn't age well.
As for HTML5, there was a chicken and egg problem. When you don't have marketshare, nobody cares about your wonderful features that nobody is using. So you have to get feature compatibility first, then marketshare, and only THEN turn to wishlist items. All that Microsoft needed to do to keep the browser wars won was keep investing in IE. Make it a moving target that nobody can catch up to.
They didn't simply because they had won. Won so completely that they thought that they could rest on their laurels.
> their marketshare only ever got as high as 30%
You write that like it was a failure. It was HUGE! In the context of the ms monopoly, it was an unbelievable and largely unmatched success.
Secondly, having a third browser overtaking it was not a failure either, but success in the goal of providing viable alternatives to the stagnating ie.
You write that like it was a failure. It was HUGE! In the context of the ms monopoly, it was an unbelievable and largely unmatched success.
Secondly, having a third browser overtaking it was not a failure either, but success in the goal of providing viable alternatives to the stagnating ie.
Remember that Netscape started out dominating this market.
Maybe the rewrite didn't cause the catastrophic loss of marketshare (I'm going to resist my urge to spend the morning researching this), but it's hard to see it as a great success in that context.
Maybe the rewrite didn't cause the catastrophic loss of marketshare (I'm going to resist my urge to spend the morning researching this), but it's hard to see it as a great success in that context.
Netscape's fall had many causes, but the biggest one was monopoly actions by Microsoft. Microsoft got sued for this, and lost. The fact that Mozilla crawled back to significant marketshare from there was unbelievably impossible. The fact that open source efforts got to the point where the web became usable again on Linux was simply amazing.
Microsoft had checked out of the browser war game in the 2000's, they had won.
All of the most important Mozilla improvements in software design, development practice changes, and testing methodologies in Firefox came in response to and after the arrival and ascendance of Chrome, not IE.
Mozilla was not destroyed by Microsoft, and Microsoft gave Mozilla ample time and ammunition to be disruptive.
I know you want to be positive on Mozilla, I want to too. But the overall program has been kindof a failure in terms of mindshare.
All of the most important Mozilla improvements in software design, development practice changes, and testing methodologies in Firefox came in response to and after the arrival and ascendance of Chrome, not IE.
Mozilla was not destroyed by Microsoft, and Microsoft gave Mozilla ample time and ammunition to be disruptive.
I know you want to be positive on Mozilla, I want to too. But the overall program has been kindof a failure in terms of mindshare.
Mozilla abandoning the addon ecosystem left very little reason to use firefox over other alternatives.
I think this kind of sourpuss attitude about Mozilla isn't helpful. What they did with addons is about maturing the platform, making it a safer operating environment for non-power users.
I believe it's a matter of time and maturity for Mozilla to support 99% of add-on requirements with their more secure, chrome-like, addon system. The fact that vimperator can't be written in today's Firefox, or that it would be a mighty pain to do so right now, is acceptable to me if it means Firefox is less hackable.
I've certainly been critical of Mozilla and dislike how the browser has been dumbed-down in many respects over the years in-service of making it an application delivery platform. But, in my opinion, stability and security have to be job #1 for Mozilla.
I believe it's a matter of time and maturity for Mozilla to support 99% of add-on requirements with their more secure, chrome-like, addon system. The fact that vimperator can't be written in today's Firefox, or that it would be a mighty pain to do so right now, is acceptable to me if it means Firefox is less hackable.
I've certainly been critical of Mozilla and dislike how the browser has been dumbed-down in many respects over the years in-service of making it an application delivery platform. But, in my opinion, stability and security have to be job #1 for Mozilla.
> you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.
What? This statements are very arbitrary.
What? This statements are very arbitrary.
It isn't really when you consider the context. Many times when people feel like doing a re-write, it's because they don't understand the old system, or the people who wrote the old system are no longer around. Otherwise... why would you need to do a single big re-write? The old guys could just fix it up. Or the new guys could spend more time reading code.
The exceptions to this would be if you were motivated to do the re-write for a good reason, like it depends on something that is no longer dependable (e.g. Java applets or Flash).
The exceptions to this would be if you were motivated to do the re-write for a good reason, like it depends on something that is no longer dependable (e.g. Java applets or Flash).
This is in line with Naur's "programming as theory building" essay [1].
Is the system "alive" or "dead"? The system is alive if the programmers that are maintaining it have the theory of the system in their heads, and can use it to inform change, and can teach that theory to others.
The system being alive is not a property of the system in isolation but a property of the relationship between the system and the programmers who work on it.
[1] http://pages.cs.wisc.edu/~remzi/Naur.pdf
Is the system "alive" or "dead"? The system is alive if the programmers that are maintaining it have the theory of the system in their heads, and can use it to inform change, and can teach that theory to others.
The system being alive is not a property of the system in isolation but a property of the relationship between the system and the programmers who work on it.
[1] http://pages.cs.wisc.edu/~remzi/Naur.pdf
Broadly I agree, lately though I've had to change some stuff that was tightly coupled to only slightly related code via generics and inheritance. Rewriting parts is the only way to disentangle things. If there is one thing that spaghetti programmers love it's inheritance.
Clean as you go sure, but in a twisted and janky codebase, full of absurdist abstract factories and eerie hall-of-mirrors template meta-programming, you have watch your step.
Deep, deep in the code there are bugs which have lain undististurbed for eons. Scrape away some cmake pus, sprinkle in the mandatory security fixes, sure no problem. But dig to deep with the 'WTF were they thinking reimplementing the preprocessor?' shovel and you'll wake the helter-skelter bugs from their heisencave into reality.
Also, you mustn't awake the Balrog. The possibly bearded old programmer, he used to be a Hero programmer, a mythical 10x coder, and he thinks he owns ALL THE CODE. He will revert your SCCS checkin and put the GOTOs back in the code.
Deep, deep in the code there are bugs which have lain undististurbed for eons. Scrape away some cmake pus, sprinkle in the mandatory security fixes, sure no problem. But dig to deep with the 'WTF were they thinking reimplementing the preprocessor?' shovel and you'll wake the helter-skelter bugs from their heisencave into reality.
Also, you mustn't awake the Balrog. The possibly bearded old programmer, he used to be a Hero programmer, a mythical 10x coder, and he thinks he owns ALL THE CODE. He will revert your SCCS checkin and put the GOTOs back in the code.
The Boy Scout Rule[0]
[0]: http://programmer.97things.oreilly.com/wiki/index.php/The_Bo...
[0]: http://programmer.97things.oreilly.com/wiki/index.php/The_Bo...
We share a similar mindset. I actually get a kick working through crappy code as I find reverse-engineering quite exciting, in a kind of "order from chaos" way. Take something crap, make it better, learn something and get paid for it. Ideal!
As someone who usually writes the crap stuff that other people get to live with, now I'm on the other end and having to make this "order from chaos". It's one of the most difficult things I've ever done.
I just hope I can figure out how to enjoy it, eventually.
At this stage the only thing that keeps me going is I'm too proud to feel ineffective and to fail at this, ugh!
I just hope I can figure out how to enjoy it, eventually.
At this stage the only thing that keeps me going is I'm too proud to feel ineffective and to fail at this, ugh!
Chin up! Here are some tips:
* Reframe the task as a game. A crime to solve if you like.
* See it as a series of black boxes that you keep subdividing (You are working top-down right?)
* Keep a [cork|black|white]board like they do in the movies with all the suspects and details of the case, with the string linking them (Do this digitally if you like)
* It's more important to know the I/O of the boxes/components than how they work, at least initially
* Be transparent with your employer about the difficulty. They know it's a mess - that's why you're there.
Good luck!
* Reframe the task as a game. A crime to solve if you like.
* See it as a series of black boxes that you keep subdividing (You are working top-down right?)
* Keep a [cork|black|white]board like they do in the movies with all the suspects and details of the case, with the string linking them (Do this digitally if you like)
* It's more important to know the I/O of the boxes/components than how they work, at least initially
* Be transparent with your employer about the difficulty. They know it's a mess - that's why you're there.
Good luck!
Nothing teaches you how your technology of choice really works like taking apart a massive horrendous codebase.
You'll be at the next level of expertise soon!
You'll be at the next level of expertise soon!
I often get more satisfaction from removing code (and keeping / improving the functionality) than I do from writing new code.
Maybe I am weird but I like doing stuff like that. I am more of an optimizer than from-scratch-creator so I like having a starting point. Then you just refactor your way through the system while adding new stuff and fixing bugs. I also like debugging and profiling :-(.
I'm with you. The worst part of a project (when I was doing them) was getting the first to end-to-end proof of concept going.
Give me profiling tools, debuggers and refactoring tools any day of the week.
Give me profiling tools, debuggers and refactoring tools any day of the week.
Nothing wrong with that! There are more of out there than we think :-)
Can i hire you both?!?
Seriously, are there many people that relish refactoring? I'd like to meet them. How to find them?
I've been thinking about marketing myself as "Code Janitor", actually :)
[deleted]
If you have any Django / Python based stuff that needs refactored and are willing to hire remote I would be up for it.
Here! I spent a lot of my early career porting legacy code from one language/platform to another and I liked that well enough. Now I spend more time refining my own code than is really necessary, just because I enjoy it.
Seems you can find them here :-)
Plenty of us out here!
Make me an offer! :-)
The elephant in the room here — and this is no judgement — is that the contractor isn't worrying about creating more technical debt or something that will fall down in a year's time. It's YAGNI taken to an extreme. As easy it is as a contractor (as I can attest) to make fun of previous implementation spacemen who came before you, they often had the laudable goal of creating something that would be easier and cheaper to work with moving forward. I've also been at - more than once - given managerial control of a large codebase driven exclusively by the need to deliver deliver deliver and had to explain to the company why development has become so much slower since they started.
> As easy it is as a contractor (as I can attest) to make fun of previous implementation spacemen who came before you, they often had the laudable goal of creating something that would be easier and cheaper to work with moving forward.
It's one thing to have the domain expertise to accurately anticipate future asks and preemptively prepare for them. But I've seen very few cases of that, compared to projects that were design pattern lasagna. Layer upon layer of abstraction to solve imaginary problems that were never real nor will ever become real. And all those abstractions cost the same as those which actually solve problems.
My approach is always to solve the problems you actually have, and no more. This includes abstractions for unit tests; that's an actual problem. (You are putting all those external dependencies behind interfaces for mocking, right?)
It's one thing to have the domain expertise to accurately anticipate future asks and preemptively prepare for them. But I've seen very few cases of that, compared to projects that were design pattern lasagna. Layer upon layer of abstraction to solve imaginary problems that were never real nor will ever become real. And all those abstractions cost the same as those which actually solve problems.
My approach is always to solve the problems you actually have, and no more. This includes abstractions for unit tests; that's an actual problem. (You are putting all those external dependencies behind interfaces for mocking, right?)
Yep, the daily work cycle at enterprise consulting.
I expected this to be using "catfish" in the same sense as the online dating world; i.e. the "catfish programmer" is one who puts all sorts of programming languages on their resume but can't actually answer any questions about what they've done in that language.
I tend to land on that position. But when I'm at the very bottom of the mud and I found the spot, I rarely rewrite a piece to make it in-your-face-clear. Sometimes I do, but more often than not I just edit few characters that are wrong.
I can remember at least one case (probably had few more, just don't remember them) when, to fix a bug, I changed just one character, after few hours of reading and understanding all the bad ideas people before me implemented there, first seeing them as complete nonsense and gradually realizing, that what they wrote does what was intended, almost.
It kind of feels good for me. I hate building though, because I'm painfully aware, how stuff looks once it's built. It's never good.
I can remember at least one case (probably had few more, just don't remember them) when, to fix a bug, I changed just one character, after few hours of reading and understanding all the bad ideas people before me implemented there, first seeing them as complete nonsense and gradually realizing, that what they wrote does what was intended, almost.
It kind of feels good for me. I hate building though, because I'm painfully aware, how stuff looks once it's built. It's never good.
I had a similar case a year ago where about two days of work resulted in a pull request that changed only one word: https://github.com/docker/distribution/pull/1578
I don't know if I'm a catfish programmer, but lately I've been completely disinterested in offices with the sorts of perks that I used to go crazy for years ago. I don't care much about free lunches or extremely nice desks or chairs or ping pong tables or whatever. That stuff is distracting. I care much more about buying my own lunch and fun.
In my experience as someone who has been in-house counsel and now outside counsel for a variety of tech startups and software development shops, and has watched this happen in the careers of a lot of people around me (usually while being the sole 'suit' in the room), the transition you are describing usually happens in the late twenties or early thirties.
It is basically the transition away from the last vestiges of a "school-like" mindset to a "career" mindset.
In the "school" mindset, your primary form of social rewards are from the people you spend your day with - when you are a kid, your friends are all at school, and even though you go to school to do schoolwork, it is still where you see your friends. In the "career" mindset, your primary social rewards are the people you spend your nights with - which are friends who you do not work with, and, importantly, your family.
In other words, as a young 20something, it is easy to still be in the mindset that the 'fun' time is when you go to the place you spend all day at and do so with a bunch of cool people. A lot of jobs, as a result, try to recreate that 'school' experience with a gym, scheduled fun activities, playtime, etc. Howev er, when you are in your late 20s, even if you don't necessarily have a family or are an introvert, the appeal of this lessens dramatically, as you naturally spend more effort trying to carve out time for your own interests - whether they be your family, your hobbies, or even just solitude and meditative peace. Accordingly, it is really just far less important that work have a bunch of perks that require that you actually be there, than for work be a professional environment that respects your time and is financially and intellectually rewarding enough to be "worth it."
It is basically the transition away from the last vestiges of a "school-like" mindset to a "career" mindset.
In the "school" mindset, your primary form of social rewards are from the people you spend your day with - when you are a kid, your friends are all at school, and even though you go to school to do schoolwork, it is still where you see your friends. In the "career" mindset, your primary social rewards are the people you spend your nights with - which are friends who you do not work with, and, importantly, your family.
In other words, as a young 20something, it is easy to still be in the mindset that the 'fun' time is when you go to the place you spend all day at and do so with a bunch of cool people. A lot of jobs, as a result, try to recreate that 'school' experience with a gym, scheduled fun activities, playtime, etc. Howev er, when you are in your late 20s, even if you don't necessarily have a family or are an introvert, the appeal of this lessens dramatically, as you naturally spend more effort trying to carve out time for your own interests - whether they be your family, your hobbies, or even just solitude and meditative peace. Accordingly, it is really just far less important that work have a bunch of perks that require that you actually be there, than for work be a professional environment that respects your time and is financially and intellectually rewarding enough to be "worth it."
damn that is exactly my situation! it happened a little earlier for me though; i'd say around 27-28. it accelerated after working for google that short bit I did
The best stretch of my career, I was going into the office on Mondays, and working from home the rest of the week. Mondays, I would go to meetings and collaborate, and plan the rest of the week, and Tuesday through Friday I was working through the pre-planned work. I've never been so productive - I've since gone back to being in the office Mon-Thursday, and my production is a shell of what it was. There's so much more distraction, and I'm wildly less happy about being there than I was when I was at home all the time.
I've recently managed to convince my boss to let me work from home for two days in a week (Mondays and Fridays). My productivity did get a huge boost (though that may be through Hawthorne effect; we'll see how it evolves over coming months), and my stress load reduced quite a lot. 3 days a week of direct, face-to-face contact with cow-orkers seems like a sustainable rate for me. 5 days a week made me tired over time.
Note that the "Catfish" urban legend originally meant something else.
In the movie the catfish term is introduced like this: "They used to tank cod from Alaska all the way to China. They'd keep them in vats in the ship. By the time the codfish reached China, the flesh was mush and tasteless. So this guy came up with the idea that if you put these cods in these big vats, put some catfish in with them and the catfish will keep the cod agile. And there are those people who are catfish in life. And they keep you on your toes. They keep you guessing, they keep you thinking, they keep you fresh. And I thank god for the catfish because we would be droll, boring and dull if we didn't have somebody nipping at our fin."
So it's indeed a bottom grundler, but with an important impact on the fish in the sunlight. Without the catfish the sunny fish would all die. The catfish keeps them agile.
So it's indeed a bottom grundler, but with an important impact on the fish in the sunlight. Without the catfish the sunny fish would all die. The catfish keeps them agile.
Some of this rings true. OK a lot of it.
Metaprogramming is often witchcraft. As is so much futureproofing. Layers upon layers of indirection because one day it might be useful.
Mighty fine framework you have there, someday you do have to write the actual code...
Metaprogramming is often witchcraft. As is so much futureproofing. Layers upon layers of indirection because one day it might be useful.
Mighty fine framework you have there, someday you do have to write the actual code...
I find that I reach for metaprogramming for two reasons.
First reason: I have been programmed into a corner. This needs to be tomorrow and a rewrite is out of the question and normally refactorings simply can't get the job done. I need to add methods at runtime or some equally nightmarish hack or the data won't be were is needs to be. I have done some like this twice both in Ruby, about has many times as I ever hope to need longjmp in my native language C++.
The other reason I reach for metaprogramming, is performance. In C++ template metaprograms used to be the only way to have what were easily calculable valuables baked into the final binary. Now there is constexper, which is still sort of black magic and many don't understand it at all. Either way being able to replace runtime code with a thing that looks like a function but actually resolves to a constant can solves certain categories of problems.
First reason: I have been programmed into a corner. This needs to be tomorrow and a rewrite is out of the question and normally refactorings simply can't get the job done. I need to add methods at runtime or some equally nightmarish hack or the data won't be were is needs to be. I have done some like this twice both in Ruby, about has many times as I ever hope to need longjmp in my native language C++.
The other reason I reach for metaprogramming, is performance. In C++ template metaprograms used to be the only way to have what were easily calculable valuables baked into the final binary. Now there is constexper, which is still sort of black magic and many don't understand it at all. Either way being able to replace runtime code with a thing that looks like a function but actually resolves to a constant can solves certain categories of problems.
> Metaprogramming is often witchcraft.
This is an advice I frequently see, and I disagree with it strongly. For some reason, people are irrationally afraid of metaprogramming, as if it was a different kind of programming. It isn't. It's regular programming, following the very same rules, except that you're automating your own work now.
I don't know; maybe it's because mainstream languages absolutely suck at metaprogramming (if they allow it at all), so people are not used to it?
I mean, it's like someone calling algebra "witchcraft". It's not witchcraft, they just never bothered to learn it.
(Related, I see this approach of lowest-common-denominator programming being popular, and I believe it's very hurtful to everyone. Programming is a profession. If you don't understand some piece of code because it uses weird language features, suck it up and learn stuff, like a real professional.)
This is an advice I frequently see, and I disagree with it strongly. For some reason, people are irrationally afraid of metaprogramming, as if it was a different kind of programming. It isn't. It's regular programming, following the very same rules, except that you're automating your own work now.
I don't know; maybe it's because mainstream languages absolutely suck at metaprogramming (if they allow it at all), so people are not used to it?
I mean, it's like someone calling algebra "witchcraft". It's not witchcraft, they just never bothered to learn it.
(Related, I see this approach of lowest-common-denominator programming being popular, and I believe it's very hurtful to everyone. Programming is a profession. If you don't understand some piece of code because it uses weird language features, suck it up and learn stuff, like a real professional.)
The problem isn't with writing or reading metaprogramming. It's in debugging issues in the program that the metaprogram writes. You have to then figure out what both the meta-code and the code does and how they interact to have a good understanding of the problem.
There's also some very powerful advantages to avoiding metaprogramming. Like, "grepping for the name of a token shows all instances where said token is relevant". This is an incredibly powerful tool, and you really miss it when poking around in new codebases with lots of magic.
There's also some very powerful advantages to avoiding metaprogramming. Like, "grepping for the name of a token shows all instances where said token is relevant". This is an incredibly powerful tool, and you really miss it when poking around in new codebases with lots of magic.
Metaprogramming frequently reduces readability of the code. Almost all Linux kernel developers and embedded systems programmers are familiar with the linked list composed only of #define 's, and other metaprogramming solutions. It doesn't mean that seeing things like that are readable or easily traced to reproduce what happened.
Maybe you are so smart you can juggle it all in your head, as Torvalds is reputed to do with the Linux kernel. The rest of us don't have the ability to hold the mental model of both the primary layer and the metaprogrammed layer in our heads without a devotion of time that would exceed our schedules.
Thankfully in C-like languages, the compilers I've worked with will let you see the post-metaprogrammed output.
C++ templates and other metaprogramming features improve readability; I'm don't mean to cast shade on metaprogramming in general, just heavily obfuscated implementations.
Maybe you are so smart you can juggle it all in your head, as Torvalds is reputed to do with the Linux kernel. The rest of us don't have the ability to hold the mental model of both the primary layer and the metaprogrammed layer in our heads without a devotion of time that would exceed our schedules.
Thankfully in C-like languages, the compilers I've worked with will let you see the post-metaprogrammed output.
C++ templates and other metaprogramming features improve readability; I'm don't mean to cast shade on metaprogramming in general, just heavily obfuscated implementations.
I think that's the part of the blog post that resonated most with me. There seems to be this perverse belief that shortening code is always a positive, no matter how much black magic it requires.
Traceability seems to always be the first thing burnt at the stake to appease the god's desire to save 3 characters; which I find strange, because it's the most fundamental requirement of good code. If you can't work back through the code to find the source of a bug, your code is an unmaintainable pile of shit. No amount of proper whitespace use will save you.
Traceability seems to always be the first thing burnt at the stake to appease the god's desire to save 3 characters; which I find strange, because it's the most fundamental requirement of good code. If you can't work back through the code to find the source of a bug, your code is an unmaintainable pile of shit. No amount of proper whitespace use will save you.
I am currently in the catfish position and have been for a few years. In my experience the #1 reason that people reach for metaprogramming (maybe 90% of all cases) is that they have just learned about the technique in the language and have not yet learned about the readability (and often performance) disadvantages.
For background, right now I am working with an internal Python framework which creates key classes from mixins at runtime with Python's type() constructor. Figuring out what is going on at any given time is very difficult and interacting with it takes days longer than would be needed normally. The author is an inexperienced Python programmer working on a key library for a very large company and we are unable to throw his work away for organisational reasons (the framework team has a lot of political will). Not sure how to think about it. These people's poor quality work keeps me in a job but honestly it makes me feel bad for all the time and money that the client is wasting.
For background, right now I am working with an internal Python framework which creates key classes from mixins at runtime with Python's type() constructor. Figuring out what is going on at any given time is very difficult and interacting with it takes days longer than would be needed normally. The author is an inexperienced Python programmer working on a key library for a very large company and we are unable to throw his work away for organisational reasons (the framework team has a lot of political will). Not sure how to think about it. These people's poor quality work keeps me in a job but honestly it makes me feel bad for all the time and money that the client is wasting.
There's a fine line to walk between too much metaprogramming and too much boilerplate.
I often find that my wish to avoid metaprogramming results in to much cloned code, when a simple annotation/reflection or conventional setup would make life a lot easier.
Like everything in programming, using or avoiding meta-programming is a balancing act.
I often find that my wish to avoid metaprogramming results in to much cloned code, when a simple annotation/reflection or conventional setup would make life a lot easier.
Like everything in programming, using or avoiding meta-programming is a balancing act.
I like the C# approach of having a ton of syntactic sugar. I mean, if you look at what a basic `yield return` loop actually compiles to... That's some crazy metaprogramming going on. But by encoding it at the language level, they help assure that the metaprogramming is accurate and universal.
* Accurate: the final construct does what the meta-construct says it should.
* Universal: everyone speaks with the same meta-constructs.
The antithesis of universal is the Lisp Curse [0], and I think that's a natural conclusion of free metaprogramming, as opposed to the constrained metaprogramming that something like C# offers.
[0] http://winestockwebdesign.com/Essays/Lisp_Curse.html
* Accurate: the final construct does what the meta-construct says it should.
* Universal: everyone speaks with the same meta-constructs.
The antithesis of universal is the Lisp Curse [0], and I think that's a natural conclusion of free metaprogramming, as opposed to the constrained metaprogramming that something like C# offers.
[0] http://winestockwebdesign.com/Essays/Lisp_Curse.html
I agree very much - but often it seems to me that younger or less experienced programmers reach for metaprogramming by default, and end up with an end-product that can be very hard to trace.
Sometimes it is a godsend.
Sometimes it is a godsend.
This speaks to me. I learned how to program in a professional environment by doing exactly this. I can play the design patterns game and I can write pretty beautiful code, but what I can really do is cut through the bullshit and all the lessons that people have learned without understanding the reasoning behind them, and get shit done fast. I love it.
Oddly enough this doesn't really resonate with me. I've done contracting for 5 years and 90% of the work was focused on new development with the opportunity to get hired after the contract was up. Now this was a few years ago and my experience was strictly in the Midwest but I never saw myself as the bottom-feeder. If anything it was a good way to work at a company you liked where you didn't know anyone on the inside to recommend you. The experience was actually rather interesting and enjoyable.
I don't think the author of the article claims that all contractors are bottom feeders.
Some of us have done this kind of work where we were intended to fix a set of bugs on a foreign code base. Whether or not the programmer is a contractor of FTE is not relevant, the experience of being a catfish programmer is.
Some of us have done this kind of work where we were intended to fix a set of bugs on a foreign code base. Whether or not the programmer is a contractor of FTE is not relevant, the experience of being a catfish programmer is.
"In the catfish world, code speaks, money changes hands, and friendships are evanescent"
:( friendships are important to everyone, this sounds like a really unhappy way to live.
:( friendships are important to everyone, this sounds like a really unhappy way to live.
By the time you reach this point you have long steady relationships and are less fascinated by the churn of strivers looking for that one 'connection' that will make them rich.
haha i wonder to what extent people in this forum are looking for that 'one connection' (i know i feel like i am a lot)
At a certain point you get to the post friendship stage of life. :-/
Well, the "post making-friends stage". Friendships you already have can last a long, long time, and if they don't, you'll definitely enter post-friendship.
I think you're taking it out of context. It's about work friends, not friends in general.
I lost a friend through contract programming. I didn't even want to be involved, as I was having a baby around that time, but he was really keen on his startup idea, and knew a sum total of zero programmers. So I passed him on to another friend while keeping an eye on the Slack/GitHub.
It started off as a copycat site, so my ex friend basically just asked for that site, with slight modifications. That was easy, so we costed it appropriately. Then of course as the idea ballooned, he wanted all sorts of bells and whistles. On top of it all, he thought he'd manage the coder himself. I told him to read a book about agile, so he could get used to the Trello card approach to managing it. He decided not to. Also there were a million other little pieces of advice that he had his own opinions on. For instance we told him copycatting a design is easy, but we can't do a new design without a designer, and that would cost both onboarding time and money. He went and got a designer anyway. And the guy quit after a week, so a new guy had to be found.
In the end we delivered what he'd asked for, but he wasn't satisfied. I told him I was giving him honest advice as a friend, and that he could easily spend another year and another salary on some yesman who would take him for a ride. So he got a yesman who told him we'd really messed it up, it wasn't professional, and so forth. And then he threatened not to pay us, so I had to threaten him with debt collectors.
Haven't talked to him since. Site came up eventually, a year and a half after we'd actually built it.
It started off as a copycat site, so my ex friend basically just asked for that site, with slight modifications. That was easy, so we costed it appropriately. Then of course as the idea ballooned, he wanted all sorts of bells and whistles. On top of it all, he thought he'd manage the coder himself. I told him to read a book about agile, so he could get used to the Trello card approach to managing it. He decided not to. Also there were a million other little pieces of advice that he had his own opinions on. For instance we told him copycatting a design is easy, but we can't do a new design without a designer, and that would cost both onboarding time and money. He went and got a designer anyway. And the guy quit after a week, so a new guy had to be found.
In the end we delivered what he'd asked for, but he wasn't satisfied. I told him I was giving him honest advice as a friend, and that he could easily spend another year and another salary on some yesman who would take him for a ride. So he got a yesman who told him we'd really messed it up, it wasn't professional, and so forth. And then he threatened not to pay us, so I had to threaten him with debt collectors.
Haven't talked to him since. Site came up eventually, a year and a half after we'd actually built it.
This is why setting up a statement of work contract at the beginning of the project is important. It allows you to defer ballooning ideas off until after the original task is done, and scope it out separately.
I say this having done a decent amount of freelancing and making the same mistake myself (of course, after having read/heard this advice multiple times).
Working for friends and not treating them exactly like any other client usually ends badly.
I say this having done a decent amount of freelancing and making the same mistake myself (of course, after having read/heard this advice multiple times).
Working for friends and not treating them exactly like any other client usually ends badly.
Not if you love code. Then code is your friend.
I would imagine that they have friends outside of their work.
I think I might be a catfish programmer. Have been contracting for several years and on daily basis have to sift through legacy spaghetti codebases originally created by full time employees or outsourced to some digital agency, fix bugs / add features in very short time (on average I stay 6 months on a contract).
If we don't change the culture in Silicon Valley soon, these "invasive catfish" are going to hold the rest of us back, like Who Killed the Electric Car https://www.youtube.com/watch?v=vRnUY6V2Knk . They were good at first, but then they realized big changes threatened their stagnant skillset. Rather than learn more, they utilize their power to keep things the same.
I think the automation of middle management positions will eliminate these archaic modes of thinking.
Having been a contractor for a short while (~1 year) and having worked with many different contractors over the years I've never seen a situation where management has been like "this part of the codebase is too much of a mess for us to handle, we need to hire a contractor to sort it out". Does that ever happen? Surely a contractor would be even less prepared than a permie to handle such a situation because they won't be familiar with the codebase?
In my experience contractors are mainly hired for development of new projects or features when they'd like to get some more hands on deck to speed up development. Or because the company would like to hire a permie but can't for whatever reason (not sure they will have enough work in the long run, can't find the right person etc.).
Also I've never seen a contractor that who's day-to-day functions were any different from that of a permanent employee. Where are these companies that let permies play ping pong for hours but have the contractors chained to their desk churning out features and reducing technical debt?
In my experience contractors are mainly hired for development of new projects or features when they'd like to get some more hands on deck to speed up development. Or because the company would like to hire a permie but can't for whatever reason (not sure they will have enough work in the long run, can't find the right person etc.).
Also I've never seen a contractor that who's day-to-day functions were any different from that of a permanent employee. Where are these companies that let permies play ping pong for hours but have the contractors chained to their desk churning out features and reducing technical debt?
In my 6 years experience I've never seen this either. Here in Germany maybe it's a little different - contractors are very common at large companies, because it can be very hard to fire people once they've passed their trial period (3-6 months). So companies can be more reluctant to make permanent hires. Another reason is that a department might have a strict limit on their head-count (of internals), but not their budget, so they can still increase their workforce by hiring contractors (don't ask me why, just big company politics).
At the two large companies I worked for, around half the team members were external. In both cases there were 3 types of worker:
1. Internal
2. External contractor & a permanent employee of a contracting ("body-leasing") company
3. External contractor & a freelancer / self-employed
In terms of the tasks and technical responsibilities you have in these roles, I didn't notice much difference. The main difference in case 3 is that you get significantly more money (like 1.5-2x more), in exchange for worse job security. Given how easy jobs are to find in the current climate, I don't understand why more people don't opt for this. In case 2 in particular, the contracting company is taking up to a 50% cut of the hourly-rate, it's kinda crazy.
At the two large companies I worked for, around half the team members were external. In both cases there were 3 types of worker:
1. Internal
2. External contractor & a permanent employee of a contracting ("body-leasing") company
3. External contractor & a freelancer / self-employed
In terms of the tasks and technical responsibilities you have in these roles, I didn't notice much difference. The main difference in case 3 is that you get significantly more money (like 1.5-2x more), in exchange for worse job security. Given how easy jobs are to find in the current climate, I don't understand why more people don't opt for this. In case 2 in particular, the contracting company is taking up to a 50% cut of the hourly-rate, it's kinda crazy.
Doing 2 in Germany.
Because when one gets sick for long periods, needs to take care of kids or close family, only gets offers in the other side of Germany for a given tech, life is way easier with 2 than 3.
Because when one gets sick for long periods, needs to take care of kids or close family, only gets offers in the other side of Germany for a given tech, life is way easier with 2 than 3.
I totally agree. I'm a 3. Whilst no job is safe, we are always "first to go", so the 1.5-2x rate is not for nothing.
When I was freelancing, I was specialized in fixing businesses/projects that got stuck due to tech debt and non-communicating teams, using a bottom-up approach.
The hardest part is changing the mentality of the team, but within a month or 3 you usually ignite the spark that gets everything back on track. Getting to the first tiny win that changes the status quo requires a lot of hard work, but once that's rolling, it's only a matter of making yourself redundant.
One caveat: the bottom-up approach works best when people introduce you as the helping-hand dev. Some people had a hard time understanding the exorbitant paycheck, when all you do is sit with the developers, not even being a PM? (TBH I've been an ad-interim PM in most of these projects for a few weeks, and it usually helps - lead by example etc).
TL;DR: businesses/teams do get stuck, and a consultant who knows what he's doing and doesn't care for titles can turn around things.
EDIT: The one thing that's lacking in this article, is the social aspect. If you are only fixing code, you are just fixing the symptoms, not the causes.
The hardest part is changing the mentality of the team, but within a month or 3 you usually ignite the spark that gets everything back on track. Getting to the first tiny win that changes the status quo requires a lot of hard work, but once that's rolling, it's only a matter of making yourself redundant.
One caveat: the bottom-up approach works best when people introduce you as the helping-hand dev. Some people had a hard time understanding the exorbitant paycheck, when all you do is sit with the developers, not even being a PM? (TBH I've been an ad-interim PM in most of these projects for a few weeks, and it usually helps - lead by example etc).
TL;DR: businesses/teams do get stuck, and a consultant who knows what he's doing and doesn't care for titles can turn around things.
EDIT: The one thing that's lacking in this article, is the social aspect. If you are only fixing code, you are just fixing the symptoms, not the causes.
This use of the word "permie" is toxic and annoying.
Annoying? Perhaps. But toxic? I don't see how..
It's all about portraying some colleagues as inferior by calling them a childish nickname.
I've known several permanent staff members who left their roles due of this kind of behaviour (contractors boasting about rates vs. salary for the same work, refusing to merge code, etc). Calling colleagues cutesy childish nicknames is definitely a start on a downward spiral
I've known several permanent staff members who left their roles due of this kind of behaviour (contractors boasting about rates vs. salary for the same work, refusing to merge code, etc). Calling colleagues cutesy childish nicknames is definitely a start on a downward spiral
As as contractor I take pride in my code and work to leave it better than when I got there. Some good points, in the essay, for sure. But overall pretty cynical.
It is difficult to survive contact with reality without becoming cynical.
> leave it better than when I got there
This can be a frightening statement depending on what 'better' means to anyone in particular. If 'better' means Enterprise Fizzbuzz, then no thanks, if 'better' means simplify and untangle spaghetti, or unwinding Enterprise Fizzbuzz then great!
This can be a frightening statement depending on what 'better' means to anyone in particular. If 'better' means Enterprise Fizzbuzz, then no thanks, if 'better' means simplify and untangle spaghetti, or unwinding Enterprise Fizzbuzz then great!
Good point. The (your) latter.
I'm a catfish. And I love it. The messier the code, the more rewarding the challenge.
Not sure I understand this motivation.
If I smashed up a lego tower, would you have more fun patching up my tower, or instead you can create a "better" new one all by yourself?
If I smashed up a lego tower, would you have more fun patching up my tower, or instead you can create a "better" new one all by yourself?
Building a new thing from scratch means there's no guarantee anyone will ever use your code. The idea could be crap, the need not there, etc.
There's satisfaction in taking a page that was taking 10secs to load and making it load in 43ms. You know you've had a big impact on the thousands, 10s of thousands, etc. people who are using it.
And building a new system tends to go to the crap programmers because people are price sensitive. It's not until they start seeing the problems that expensive programmers turn up.
I met this game Dev contractor once in his 40s, he was complaining how he never gets allowed to make a game, they get the inexpensive graduates to make the game, then parachute him in at the 11th hour to "optimize" it, which is basically tidying up the pile of shit the inexperienced Devs made.
There's satisfaction in taking a page that was taking 10secs to load and making it load in 43ms. You know you've had a big impact on the thousands, 10s of thousands, etc. people who are using it.
And building a new system tends to go to the crap programmers because people are price sensitive. It's not until they start seeing the problems that expensive programmers turn up.
I met this game Dev contractor once in his 40s, he was complaining how he never gets allowed to make a game, they get the inexpensive graduates to make the game, then parachute him in at the 11th hour to "optimize" it, which is basically tidying up the pile of shit the inexperienced Devs made.
Yes but I would have more fun coming up with it in 43ms in the first place. No need to artificially benchmark yourself against an old version of code. The market is the real benchmark - without the baggage of recode.
re crap programmers - I don't doubt that this kind of behavior exists, and certainly with the success of the games industry and the extremely low barriers to entry (unity/unreal/steam/app store etc), this behavior may even be commonplace.
If I was you I would have advised the senior dev to find another job. A company that operates like that is looking for code monkeys, not professional software engineers, and any such professional software engineers won't hang around for long.
re crap programmers - I don't doubt that this kind of behavior exists, and certainly with the success of the games industry and the extremely low barriers to entry (unity/unreal/steam/app store etc), this behavior may even be commonplace.
If I was you I would have advised the senior dev to find another job. A company that operates like that is looking for code monkeys, not professional software engineers, and any such professional software engineers won't hang around for long.
Make no mistake, if you hand me a smashed LEGO tower and ask me to "fix it" (and pay me to do so), then I'll definitely take some creative liberties along the way while rebuilding it.
> but the summoning of the demons from the 7th layer of hell and release a Stephen
> King blood-fest on the planet.
I was expecting it to be Wolfram on that second line :|
> King blood-fest on the planet.
I was expecting it to be Wolfram on that second line :|
I am currently a catfish programmer and not enjoying it. I now feel like a garbageman because I see lots of garbage and rarely given new code to write. I now spend more time reading garbage code and trying to figure out how it works in a matter of hours. It all started last year October when I took a contracting job.
Why is my system slow?
$ grep -R "map" *
reduce(filter even? (apply ( 3) (map inc (i for i in (filter even? collection)))))*
What's with the dissing on map? Awkward code like that can be written in lots of ways... (rewrite it with transducers, friend catfish, rewrite it with transducers!)
$ grep -R "map" *
reduce(filter even? (apply ( 3) (map inc (i for i in (filter even? collection)))))*
What's with the dissing on map? Awkward code like that can be written in lots of ways... (rewrite it with transducers, friend catfish, rewrite it with transducers!)
if I read this correctly, the reduce statement here is reducing an always-empty collection.
<3
Searching "map" was an entry into the larger joke, but not sure if it came across on the psuedocode.
Searching "map" was an entry into the larger joke, but not sure if it came across on the psuedocode.
Was it a 'functional programmers know the value of everything and the cost of nothing' kind of joke?
Oh, this hits close to home. Warning: Venting through wall of text follows.
My first professional programming experience was in the early 2000's fixing and maintaining a Perl code from the mid-1990's. I wasn't a contractor, but the original author was no longer available, and there was little-to-no comprehensive knowledge about the code base in the company. We had plenty of people that could dive in and learn and fix, but as often as not, the answer to "how does that go about doing that" was "I guess we'll find out".
Later, I went to work for a local IT consultancy, and occasionally did short term and long term contractual software engineering. The majority of the horror stories I have are from this period.
I worked on a Payday loan company's code base where the original author was one of the owners, but was largely absent by the time I was working on it, due to personality and substance abuse issues. Once when making a change to the portion of the system that generated the ACH deposit file that was submitted to deliver money to customers, I noticed a commented out line that added another row, all statically defined, to put a couple thousand in a specific account. The comment above it said something to the effect "XXX's vacation allowance", where XXX was the absent owner and original author.
I worked on extending open source call center software which was essentially a bunch of multi-thousand line Perl scripts run through Aseterisk. Unfortunately, the original authors either didn't know about use strict, didn't know what scope was, and didn't know how to pass arguments to functions, or it was all an elaborate way to generate consulting feels for the original authors. Every function call was preceded by setting global variables which were then used within the function. If multiple SQL queries were needed, it was always "$stmtA = .." then "$stmtB = ". Prepared statements and variable binding? You wish. Generally, about 20%-80% of the code of any particular script (of well over 30) was generally shared with 2-5 other scripts, with no abstraction to a shared module, making the possiblity of changing one spot but not others likely, and corruption of the SQL data controlling the state of the system likely. The SQL schema itself wasn't exactly a dream to work with either...
I worked on fixing an implementation of a financial services company's rating algorithm implemented purely in SQL. The original IT employee responsible had disappeared one Thursday, and I'm not sure if they ever figured out what happened to him. The general vibe I got from them was that he probably took off on a vacation and decided not to come back. The code wasn't horrible, but making fixes to page-length dense SQL statements based on vague directions that certain stocks don't quite match the output for the Excel formula the owner developed years before is nerve wracking, when the entire business is generating reports based off this formula and selling access, and they need changes to this formula yesterday, and have little in the way of formal verification of the output.
Finally, a story to somewhat temper the WTF stories above. When returning a decade later to the company of first job, I ended up doing most the heavy work on the ancient mid-1990's code that ran their custom CRM, having had experience with it when working on it in the early 2000's. This software was always baffling, because the original author, who while to my understanding was somewhat of a Perl novice when he began the project had made the extremely odd decision to forego functions for a large set of twenty or so chained GOTO statements for each "route" (action param, in this case), instead of a simple cascaded if statement to function calls for each route, which is not only easier but much more likely to be the first choice for a novice (IMO). I finally determined the reason for this when making a larger structural change to fix this. The code was meant to (and did) run through mod_perl. Mod_perl speeds up Perl by taking the script, and essentially wrapping the content in a function, and persisting it. Unfortunately, if you have a bunch of functions defined in another function and they happen to use even just a couple "global" variables (not so global now, since they are defined in the outer function), you get closures, and data persisting between HTTP requests that should not. Using GOTO statements was a somewhat crazy, but definitely functional, way around this. Sometimes the WTF you've just encountered has justification, and it takes a deep dive to understand the code enough to know why.
Oh, that feels better. It's nice to vent every once in a while.
My first professional programming experience was in the early 2000's fixing and maintaining a Perl code from the mid-1990's. I wasn't a contractor, but the original author was no longer available, and there was little-to-no comprehensive knowledge about the code base in the company. We had plenty of people that could dive in and learn and fix, but as often as not, the answer to "how does that go about doing that" was "I guess we'll find out".
Later, I went to work for a local IT consultancy, and occasionally did short term and long term contractual software engineering. The majority of the horror stories I have are from this period.
I worked on a Payday loan company's code base where the original author was one of the owners, but was largely absent by the time I was working on it, due to personality and substance abuse issues. Once when making a change to the portion of the system that generated the ACH deposit file that was submitted to deliver money to customers, I noticed a commented out line that added another row, all statically defined, to put a couple thousand in a specific account. The comment above it said something to the effect "XXX's vacation allowance", where XXX was the absent owner and original author.
I worked on extending open source call center software which was essentially a bunch of multi-thousand line Perl scripts run through Aseterisk. Unfortunately, the original authors either didn't know about use strict, didn't know what scope was, and didn't know how to pass arguments to functions, or it was all an elaborate way to generate consulting feels for the original authors. Every function call was preceded by setting global variables which were then used within the function. If multiple SQL queries were needed, it was always "$stmtA = .." then "$stmtB = ". Prepared statements and variable binding? You wish. Generally, about 20%-80% of the code of any particular script (of well over 30) was generally shared with 2-5 other scripts, with no abstraction to a shared module, making the possiblity of changing one spot but not others likely, and corruption of the SQL data controlling the state of the system likely. The SQL schema itself wasn't exactly a dream to work with either...
I worked on fixing an implementation of a financial services company's rating algorithm implemented purely in SQL. The original IT employee responsible had disappeared one Thursday, and I'm not sure if they ever figured out what happened to him. The general vibe I got from them was that he probably took off on a vacation and decided not to come back. The code wasn't horrible, but making fixes to page-length dense SQL statements based on vague directions that certain stocks don't quite match the output for the Excel formula the owner developed years before is nerve wracking, when the entire business is generating reports based off this formula and selling access, and they need changes to this formula yesterday, and have little in the way of formal verification of the output.
Finally, a story to somewhat temper the WTF stories above. When returning a decade later to the company of first job, I ended up doing most the heavy work on the ancient mid-1990's code that ran their custom CRM, having had experience with it when working on it in the early 2000's. This software was always baffling, because the original author, who while to my understanding was somewhat of a Perl novice when he began the project had made the extremely odd decision to forego functions for a large set of twenty or so chained GOTO statements for each "route" (action param, in this case), instead of a simple cascaded if statement to function calls for each route, which is not only easier but much more likely to be the first choice for a novice (IMO). I finally determined the reason for this when making a larger structural change to fix this. The code was meant to (and did) run through mod_perl. Mod_perl speeds up Perl by taking the script, and essentially wrapping the content in a function, and persisting it. Unfortunately, if you have a bunch of functions defined in another function and they happen to use even just a couple "global" variables (not so global now, since they are defined in the outer function), you get closures, and data persisting between HTTP requests that should not. Using GOTO statements was a somewhat crazy, but definitely functional, way around this. Sometimes the WTF you've just encountered has justification, and it takes a deep dive to understand the code enough to know why.
Oh, that feels better. It's nice to vent every once in a while.
> Sometimes the WTF you've just encountered has justification, and it takes a deep dive to understand the code enough to know why.
God forbid some documentation. At a previous employer I was consistently baffled at how nearly all information about the mission critical application (and the business) was distributed through random verbal conversation, with the remainder coming from those deep dives into the code (at least until I could no longer hold my breath). There was literally zero documentation for an application with 1 million lines in the source tree and another million in SQL stored procedures (!!!). The size of the project alone was shocking considering it was a fairly standard line of business app, albeit with inventory, HR and customer interaction all rolled into one, but the experience was just about as bad as it gets for development and organizational practices.
God forbid some documentation. At a previous employer I was consistently baffled at how nearly all information about the mission critical application (and the business) was distributed through random verbal conversation, with the remainder coming from those deep dives into the code (at least until I could no longer hold my breath). There was literally zero documentation for an application with 1 million lines in the source tree and another million in SQL stored procedures (!!!). The size of the project alone was shocking considering it was a fairly standard line of business app, albeit with inventory, HR and customer interaction all rolled into one, but the experience was just about as bad as it gets for development and organizational practices.
Entertaining stories!
The GOTO programmer probably learned to code only from reading BASIC programs. I didn't know about functions until I was formally taught in my high school programming class.
The GOTO programmer probably learned to code only from reading BASIC programs. I didn't know about functions until I was formally taught in my high school programming class.
I'd imagine that the real catfish aren't posting to HN. They're coding.
And here I was thinking that this was going to devolve into a series of Betcha I Can / Hold My Beer anecdotes.
>The code that makes it into The Daily WTF[1] has no peer to many things a catfish programmer sees on an hourly basis.
Hah. Although as someone who did contribute to Daily WTF from my recent job, a lot of the code was much better than the piece I found.
God help you if you don't have a really smart IDE though.
Hah. Although as someone who did contribute to Daily WTF from my recent job, a lot of the code was much better than the piece I found.
God help you if you don't have a really smart IDE though.
I understand the analogy and I like how the reality of the job is described. But I prefer the term 'mercenary' to 'catfish'... much less depressing!
I did not get the bit about "invasive species"
Blue and Flathead catfish despite being native to a good portion of the United States are considered invasive in some places (parts of Florida as well as further north in the Chesapeake Bay) where they have been illegally introduced.
There are also some tropical catfish that made it into Southern Florida that are also considered invasive.
That said, I really don't get what the author meant either.
There are also some tropical catfish that made it into Southern Florida that are also considered invasive.
That said, I really don't get what the author meant either.
I think he was talking about hypothetical slackers that work as FTEs. If not for their fuck ups, The spaghetti code wouldn't exist and neither would the job of cleaning it up.
[deleted]
i believe he was talking about the contractors who oversell their skills and end up leaving the overall codebase worse than they found it
Plot twist: We're all catfish programmers...
Thank you! It's like everyone has missed the point of the story here...
Yup. Me to a tee. Really glad I read this.
I've found contract work tends to increase technical debt rather than decrease it. Contractors never say no. It's not their fault. They're not paid to say no. It doesn't matter if the work is "remove this emissions counter when x occurs," they just do what they're told. No push back. Push back means no contract.
If my PM asks me to hard code something, I understand the business well enough to know when it's a bad idea and when it's okay. Sometimes I say no, that's a 3 month project. They run out, get a contractor, who says yes, 1 week. Now I'm stuck with a 12 month repair job instead, because it has to be fixed in production.
I don't play ping pong or chat around the coffee maker either. I'm too busy cleaning up messes and trying to set things right so the server doesn't catch fire and force me to come in on my weekend.
Some days, I hate programming full time. I wish I was a contractor who would say "Sure, 1 week." I'd get all the glory. "Wow, that was fast. What a brilliant programmer." I'd hate myself for what I did to other programmers though. Bottom feeders, indeed.
If my PM asks me to hard code something, I understand the business well enough to know when it's a bad idea and when it's okay. Sometimes I say no, that's a 3 month project. They run out, get a contractor, who says yes, 1 week. Now I'm stuck with a 12 month repair job instead, because it has to be fixed in production.
I don't play ping pong or chat around the coffee maker either. I'm too busy cleaning up messes and trying to set things right so the server doesn't catch fire and force me to come in on my weekend.
Some days, I hate programming full time. I wish I was a contractor who would say "Sure, 1 week." I'd get all the glory. "Wow, that was fast. What a brilliant programmer." I'd hate myself for what I did to other programmers though. Bottom feeders, indeed.
> Contractors never say no. It's not their fault. They're not paid to say no.
I'm a contractor, working for a consulting firm, and we say no all the time. Sometimes it's not a hard no, but more of a gentle nudge in a better direction. But we often advise our clients away from certain requests because that's what we're paid for. We're the experts and they value our expertise, that's why they hired us.
I know for a fact that what you describe exists, because about a quarter of our jobs involve cleaning up after someone like that, but I wouldn't say it's a feature of contractors in general but of cheap contractors.
I'm a contractor, working for a consulting firm, and we say no all the time. Sometimes it's not a hard no, but more of a gentle nudge in a better direction. But we often advise our clients away from certain requests because that's what we're paid for. We're the experts and they value our expertise, that's why they hired us.
I know for a fact that what you describe exists, because about a quarter of our jobs involve cleaning up after someone like that, but I wouldn't say it's a feature of contractors in general but of cheap contractors.
You said a key word here. "Consultant". I would say you, too, are a consultant, by dint of working for a consulting firm.
A consulting firm, at least, a good one, cares about reputation. There's also a huge level of buy in from the business. You said it, -you're the expert-. That's a fact the business hiring you recognizes, and is why they're paying consulting fees. So yes, you're empowered to say no.
A standalone contractor, however, was not hired for his/her expertise, but to instead be slotted in to an existing project to churn out features, or fix things. The company hiring them has invested far less, sought out far less, stands to both gain and lose far less if things sour, and will have no qualms terminating them if so inclined.
I've seen it firsthand, over and over again. Contractors are second class citizens to employees. But employees are second class citizens to consultants.
A consulting firm, at least, a good one, cares about reputation. There's also a huge level of buy in from the business. You said it, -you're the expert-. That's a fact the business hiring you recognizes, and is why they're paying consulting fees. So yes, you're empowered to say no.
A standalone contractor, however, was not hired for his/her expertise, but to instead be slotted in to an existing project to churn out features, or fix things. The company hiring them has invested far less, sought out far less, stands to both gain and lose far less if things sour, and will have no qualms terminating them if so inclined.
I've seen it firsthand, over and over again. Contractors are second class citizens to employees. But employees are second class citizens to consultants.
This is very true. Like most things in life, we get what we pay for - usually. It's the difference between an engineer and a "code slinger".
I find quite the opposite. Having worked as a permie and as a contractor, I have found that contractors can be much more likely to push back. They are much less susceptible to the group-think that afflicts permanent developers, and (possibly due to their higher cost) their opinion can be taken more seriously.
It's really quite unfortunate. But while true in most cases, it's also not always the case. Having done contract work/consulting for many years, I actually say no quite often. It's surprisingly common for business, especially small and medium sized ones, to make changes that do not improve their business, or even hurt it.
Some read an article online saying "big red buttons increase conversion", and want that along with a full revamp of their system, even though it may not improve anything for their business. I believe that any consultant worth their salt should be cognizant of this, and look out for their client's interests. There is often a gap between what a client says they want and what they really want. Being able to identify that difference is key in delivering value and having leads come in without additional effort.
Everyone can mash together a solution, but it's incredibly rare for a business owner to find a contractor who looks out for them and prevents them from throwing cash at a non-issue. Most business owners have worked with many contractors, and when they find someone who truly cares, most reciprocate.
Some read an article online saying "big red buttons increase conversion", and want that along with a full revamp of their system, even though it may not improve anything for their business. I believe that any consultant worth their salt should be cognizant of this, and look out for their client's interests. There is often a gap between what a client says they want and what they really want. Being able to identify that difference is key in delivering value and having leads come in without additional effort.
Everyone can mash together a solution, but it's incredibly rare for a business owner to find a contractor who looks out for them and prevents them from throwing cash at a non-issue. Most business owners have worked with many contractors, and when they find someone who truly cares, most reciprocate.
> It doesn't matter if the work is "remove this emissions counter when x occurs," they just do what they're told.
Nice one. That is pretty topical. I wouldn't be surprised if it was a contractor who wrote it in (without knowing the context) because the original engineers declined.
Edit: I believe the poster was referring to the Volkswagen scandal, since it appears some HNers aren't understanding what I'm talking about.
Nice one. That is pretty topical. I wouldn't be surprised if it was a contractor who wrote it in (without knowing the context) because the original engineers declined.
Edit: I believe the poster was referring to the Volkswagen scandal, since it appears some HNers aren't understanding what I'm talking about.
I'm a contractor and always push back. The person who will have trouble understanding the code and delivering features isn't someone down the line, it's me in just a couple of weeks time.
The only way I can deliver consistently is to fix things as I go.
To be fair, I've had contracts finish early because of taking this approach.
Most contracts are not just 1 week, but for months.
If I just bash out any old shit then not only will the next dev be cursing me but I won't get any better along the way.
If you don't do a good job, then why bother at all?
Maybe you should try contracting, if you don't like it or there is bad office politics you always know you will be somewhere else in a matter of months.
The only way I can deliver consistently is to fix things as I go.
To be fair, I've had contracts finish early because of taking this approach.
Most contracts are not just 1 week, but for months.
If I just bash out any old shit then not only will the next dev be cursing me but I won't get any better along the way.
If you don't do a good job, then why bother at all?
Maybe you should try contracting, if you don't like it or there is bad office politics you always know you will be somewhere else in a matter of months.
I think dysfunction like you describe comes from organisations that don't value developer opinion. I don't particularly blame some contractors for taking advantage of that and making a living from it, but it reflects the organisation, not the contractors per se.
My last company was like that and contractors played the role of "yes"-person all the time. Where I am now, though is very different. Everyone discusses ideas and decisions are not taken without considering options. Contractors get stuck in with everyone else and don't just shovel bad solutions to problems.
My last company was like that and contractors played the role of "yes"-person all the time. Where I am now, though is very different. Everyone discusses ideas and decisions are not taken without considering options. Contractors get stuck in with everyone else and don't just shovel bad solutions to problems.
> Contractors never say no.
No. :-)
If the contractor/consultant was good, what you are likely experiencing is at the endpoint of a longer and larger process. Behind doors closed to you, in the procurement meetings you probably aren't privy to, the PM is presenting to the contractor a set of constraints that presume your adverse timeline.
The good contractors will point out drawbacks A, B, and C if the time constraint is not relaxed. A manager somewhere will likely dismiss that and say "we understand and accept the tradeoffs". Usually that is exchanged over email because the contractor wants a paper trail. And usually that exchange never is shared with the technical staff, much less make it into the project documentation. This is poor leadership (and in human nature), ostriching away inconvenient engineering realities, and in my experience one of the primary reasons you end up with what you described.
There are crappy body shop-supplied contractors, to be sure. But you usually can exert a veto at the technical vetting stage over that. However, it is the rare organization that includes the technical staff in the entire procurement process.
You are also possibly not communicating your "no" effectively enough. Usually this happens when your efforts at managing upwards and drawing boundaries are not getting the attention you desire.
You can fix this in all but the most egregiously dysfunctional organizations, but it is hard work for most technical individual contributors, because it requires developing social, communication and emotional skills that are difficult to master for anyone. The remedy delivery varies on a case-by-case basis. Sometimes it is as simple as working with the contractor to ring fence the solution they are procured to deliver, deliberately treating everything the code touches as tainted through specially marking it in debugging output so you can easily troubleshoot it later. Sometimes you have to wade into project management meetings and explain in ELI5 language without sounding condescending the tradeoffs being juggled, and hold accountable the decisions without letting a hint of "I told you so" creep into your tone.
You will always have to ensure you stay on top of what you are working on now, what you plan to work on in the pipeline, time commitments for each, and be able to tell week to week the impact on delivery timelines for everything based upon recent developments, and boil it all down to management as "if we do this, then that means these other goals will delay by this much", where the goal is expressed in business terms when possible. Yes, this means you are doing project management. Yes, this means you are doing much of the work of your project manager. Then why have a project manager, you ask? Because their job is not to help you; that's mostly incidental if it happens. Their job is to help communicate what is happening in the project to your managers.
As a young whelp, I used to have a "c0d3 == l1f3" approach to my work, and doing any of this other work was sheer agony, as I sucked at it at first. It got a lot easier for me when I modeled all of it as different communications protocols with different manager types, and experienced that if I put in the work to reach out with these different communications styles, lots of managers became my enthusiastic sponsors (and by extension, when I made the jump to consulting, this helped my selling skills). YMMV, of course. Hope this alternate perspective helps.
No. :-)
If the contractor/consultant was good, what you are likely experiencing is at the endpoint of a longer and larger process. Behind doors closed to you, in the procurement meetings you probably aren't privy to, the PM is presenting to the contractor a set of constraints that presume your adverse timeline.
The good contractors will point out drawbacks A, B, and C if the time constraint is not relaxed. A manager somewhere will likely dismiss that and say "we understand and accept the tradeoffs". Usually that is exchanged over email because the contractor wants a paper trail. And usually that exchange never is shared with the technical staff, much less make it into the project documentation. This is poor leadership (and in human nature), ostriching away inconvenient engineering realities, and in my experience one of the primary reasons you end up with what you described.
There are crappy body shop-supplied contractors, to be sure. But you usually can exert a veto at the technical vetting stage over that. However, it is the rare organization that includes the technical staff in the entire procurement process.
You are also possibly not communicating your "no" effectively enough. Usually this happens when your efforts at managing upwards and drawing boundaries are not getting the attention you desire.
You can fix this in all but the most egregiously dysfunctional organizations, but it is hard work for most technical individual contributors, because it requires developing social, communication and emotional skills that are difficult to master for anyone. The remedy delivery varies on a case-by-case basis. Sometimes it is as simple as working with the contractor to ring fence the solution they are procured to deliver, deliberately treating everything the code touches as tainted through specially marking it in debugging output so you can easily troubleshoot it later. Sometimes you have to wade into project management meetings and explain in ELI5 language without sounding condescending the tradeoffs being juggled, and hold accountable the decisions without letting a hint of "I told you so" creep into your tone.
You will always have to ensure you stay on top of what you are working on now, what you plan to work on in the pipeline, time commitments for each, and be able to tell week to week the impact on delivery timelines for everything based upon recent developments, and boil it all down to management as "if we do this, then that means these other goals will delay by this much", where the goal is expressed in business terms when possible. Yes, this means you are doing project management. Yes, this means you are doing much of the work of your project manager. Then why have a project manager, you ask? Because their job is not to help you; that's mostly incidental if it happens. Their job is to help communicate what is happening in the project to your managers.
As a young whelp, I used to have a "c0d3 == l1f3" approach to my work, and doing any of this other work was sheer agony, as I sucked at it at first. It got a lot easier for me when I modeled all of it as different communications protocols with different manager types, and experienced that if I put in the work to reach out with these different communications styles, lots of managers became my enthusiastic sponsors (and by extension, when I made the jump to consulting, this helped my selling skills). YMMV, of course. Hope this alternate perspective helps.
I love this. The catfish moniker is weird but I have definitely learned these lessons. I write very simple code because I've seen the hotshot stuff go bad, not because I don't understand the hotshot stuff.
But, this way of working involves little glory or reward besides the money. You'll never be the genius that created the beautiful new thing, you'll always be the janitor who's stuck with fixing all the mistakes of the "genius". So just know that.
One time a coworker said to me, you know, your stuff always just works and I never run into problems with it. That's about the extent of praise you'll get when you work like this. So know that too.
But, this way of working involves little glory or reward besides the money. You'll never be the genius that created the beautiful new thing, you'll always be the janitor who's stuck with fixing all the mistakes of the "genius". So just know that.
One time a coworker said to me, you know, your stuff always just works and I never run into problems with it. That's about the extent of praise you'll get when you work like this. So know that too.
> I write very simple code because I've seen the hotshot stuff go bad, not because I don't understand the hotshot stuff.
There is nothing like coming back and fixing some code you wrote a year ago (or longer) on a Friday afternoon when you have a train to catch and being able to pull it off because you can actually read that code and understand how it works right away.
At first I missed the twisted pride in coming up with overly clever solutions, but I can always scratch that itch in toy projects I work on in my free time. But being able to call it a day on time and not having to work late in order to figure out WTF I was thinking a year ago is priceless.
And as for glory - I still have to defend a programmer who quit long ago, because I was able to dive into his Delphi code base without any prior knowledge of Delphi or any knowledge of the problem domain and make meaningful changes to that code within a few days.
Okay, so I had to pepper our accountants with questions relentlessly for hours, but in the end I understood enough of what they told me to make that change. ;-)
There is nothing like coming back and fixing some code you wrote a year ago (or longer) on a Friday afternoon when you have a train to catch and being able to pull it off because you can actually read that code and understand how it works right away.
At first I missed the twisted pride in coming up with overly clever solutions, but I can always scratch that itch in toy projects I work on in my free time. But being able to call it a day on time and not having to work late in order to figure out WTF I was thinking a year ago is priceless.
And as for glory - I still have to defend a programmer who quit long ago, because I was able to dive into his Delphi code base without any prior knowledge of Delphi or any knowledge of the problem domain and make meaningful changes to that code within a few days.
Okay, so I had to pepper our accountants with questions relentlessly for hours, but in the end I understood enough of what they told me to make that change. ;-)
I work with a bunch of scientists and engineers(the non software type) I've seen some very 'ugly' code written by very smart people who they were never taught CS concepts so they often don't know about efficient algorithms or anything like that but they crank out tonnes of code that does useful work.
I kind of fall into this janitor role. I often get people stopping by my desk how can I speed this up. Can you help me fix this bug etc. I think it's because I fall into the sweet spot where I have the domain knowledge (I have engineering degree) so that I can understand the problem they are trying to solve.
It's also amusing that no matter the language (C, C++, Java, Basic etc) a large subset churn out code that looks a lot like Fortran 77.
I kind of fall into this janitor role. I often get people stopping by my desk how can I speed this up. Can you help me fix this bug etc. I think it's because I fall into the sweet spot where I have the domain knowledge (I have engineering degree) so that I can understand the problem they are trying to solve.
It's also amusing that no matter the language (C, C++, Java, Basic etc) a large subset churn out code that looks a lot like Fortran 77.
> a large subset churn out code that looks a lot like Fortran 77.
REAL PROGRAMMERS can write FORTRAN code in any language, right? ;-)
REAL PROGRAMMERS can write FORTRAN code in any language, right? ;-)
As a contractor, that's fine. Because I do not seek glory in the office. I seek glory 2 miles up on a Tuesday morning hike while all the zombies are at the office. Also, there's no traffic so, :).
EDIT: 'miles up'
EDIT: 'miles up'
I think that is depressing. I'm not saying don't go for a bike ride, but why not seek glory in something you spend 1/3 (+) of your life doing?
Why not seek glory in what you want to seek glory in and stop judging others based on what they want to seek glory in?
Fair, but who said I spent 1/3 of my life doing it?
True. My point was that people spend a considerable amount of energy/time going to work, so might as well "apply" oneself. Not sure if that's what you mean by glory. But the two are usually linked.
That's cool,I've never been a contractor. Just always seem to end up cleaning up after old messes.
>Taking breaks to play games, chat around coffee, or taking a few minutes to walk around the office is a non-existent element of life. An 8 hour work day is exactly that: 8 hours of pure work.
I don't understand how some programmers can supposedly work for 8 hours straight. I often have to take breaks to think about how I want to best implement the next thing, or what exactly I should be working on.
I don't understand how some programmers can supposedly work for 8 hours straight. I often have to take breaks to think about how I want to best implement the next thing, or what exactly I should be working on.
Writing code is different than reading code, it suits different work patterns. One is dealing with software architecture and the other is doing software archaeology.
In the described catfish role, you don't get to spend any meaningful amount of time thinking about how to best implement the next thing; sure, you do some of that, but almost all the time gets spent trying to understand how the heck that thing was implemented (and why) (and why??????), and that means that (a) you don't really get progress unless you're looking at or touching that artifact, and (b) you really want to avoid context switching; if you've spent three hours building up a vague picture in your mind about what something large and weird is supposed to mean, then you'll have to repeat half of that if you take a lunch break and talk about other matters. When you do figure that out, though, the fix or rewrite generally is quick, easy and routine.
In the described catfish role, you don't get to spend any meaningful amount of time thinking about how to best implement the next thing; sure, you do some of that, but almost all the time gets spent trying to understand how the heck that thing was implemented (and why) (and why??????), and that means that (a) you don't really get progress unless you're looking at or touching that artifact, and (b) you really want to avoid context switching; if you've spent three hours building up a vague picture in your mind about what something large and weird is supposed to mean, then you'll have to repeat half of that if you take a lunch break and talk about other matters. When you do figure that out, though, the fix or rewrite generally is quick, easy and routine.
This is maybe one of the greatest advantages I have gained in my years of experience at one company. When I started, I was inheriting the code of other people, with all the baggage of trying to understand it and keep the mental model intact when I needed to make changes. Over time, I've largely rewritten all of the products that are still current, as requirements and dependencies have changed. I'm reminded of the probably apocryphal story of Nikola Tesla and Henry Ford[1]
[1] http://www.snopes.com/business/genius/where.asp
[1] http://www.snopes.com/business/genius/where.asp
This is a perfect description of what I was expressing. I like the archaeologist angle (knowing nothing of archaeology, of course).
So much of the work is browsing files and reading, which is different than creating. It's a different challenge: enjoyable in its own way.
So much of the work is browsing files and reading, which is different than creating. It's a different challenge: enjoyable in its own way.
Yesterday I had about 5 hours of straight work within the usual 8 hour window (different from the "you only get x < 8 hours of not necessarily continuous productive work per 8 hours" some people like to claim), not even getting up from my chair once. I had to psyche myself up for it after lunch though. The reason is I had to work on finding a solution to a deep and complicated bug, and I knew it would take a long time. (I had to work on it some more today to fix some issues with what I settled on last night.) But I was able to devote my entire focus to it and put aside code reviews and doc reviews and email checking and so forth until I had a potential fix.
Most days I don't have such long periods of continuous focus. The culprit is usually multitasking. Context switching carries a cost for me. Even if the context is justified (important meeting, hammock-time to figure something out, lunch break) there's a cost. I'm somewhat jealous of people who seem to have such a minimum cost and can go even more than 8 hours grinding away and working very productively indeed, since I can taste that focus on occasion, and it'd be cool to have it always. I probably wouldn't spend most of it on work-work though.
Most days I don't have such long periods of continuous focus. The culprit is usually multitasking. Context switching carries a cost for me. Even if the context is justified (important meeting, hammock-time to figure something out, lunch break) there's a cost. I'm somewhat jealous of people who seem to have such a minimum cost and can go even more than 8 hours grinding away and working very productively indeed, since I can taste that focus on occasion, and it'd be cool to have it always. I probably wouldn't spend most of it on work-work though.
I found a super helpful skill to develop is the ability to context switch quickly. Don't be a slave to "the zone". Interruptions happen, and the person who has the discipline to require only 2-5 minutes to get back into the programming zone is more productive than the one who needs 30 minutes after his/her concentration gets broken. I've found the single biggest thing that helped me to work on context switching quickly is having a child--because kids don't give a shit if you're in the zone. They just barge in and interrupt you, and you have to deal with it because family.
I mean, so you're super-productive in continuous 5 hour batches?? Great, we all are! But no business on Earth is like that. Are you also super-productive when your day is punctuated by meetings, phone calls, and open-office distractions? That environment seems to be more common in this day and age.
I mean, so you're super-productive in continuous 5 hour batches?? Great, we all are! But no business on Earth is like that. Are you also super-productive when your day is punctuated by meetings, phone calls, and open-office distractions? That environment seems to be more common in this day and age.
I don't think most developers are wired to be able to do this, no matter how hard we try. You could apply this maxim to anything: "Just try really hard and practice a lot and you can run a 3-minute mile!"
Most productive developers I know attend meetings and then disappear in the building to a random nook to write code. Or they show up at noon and stay till 8 so they get a few hours without interruptions.
Most productive developers I know attend meetings and then disappear in the building to a random nook to write code. Or they show up at noon and stay till 8 so they get a few hours without interruptions.
I'm not a fan of the sink-or-swim approach to gaining skills because when people advocate for it they discount the probability of sinking. I know some people who had kids and tried working from home, every one of them couldn't build the skill to be as or more productive as they were before kids. And some of these people have kids that are now entering middle school, it's not like they haven't had years of practice trying to do it. But it's fine, we don't need to be highly productive let alone super productive all the time like the catfish.
If you treat meetings, calls, socializing with your coworkers, etc., as part of "work" instead of distractions from "real work" (that you do best in "the zone"), then it's possible to be pretty productive like that too. My context switch time depends on what I'm switching to. I haven't figured out a good way to switch from deep coding -> meetings -> deep coding efficiently, but I can switch from code reviews -> meetings -> pinball -> meetings -> emails -> direction clarification... pretty well. It's improved with practice, sure. But what I find more useful is to plan around what type of day I'm expecting to have, then it's not that hard to be productive in the context of that day or week. Most days I don't even try doing any serious coding before the morning standup, so it's a great time to do other needed things, and depending on what the rest of the day is and what I need to prioritize right now I may or may not have some good coding sessions intermixed with other things. Days of pure zone are rare, which is why I cherish them (at least with positive usages, the bug-zone days are kind of bittersweet because things shouldn't be this hard and probably wouldn't be in a non-legacy system), but I don't need that to be productive. I don't even need to do serious coding as much as I want, a lot of work is just gluing things together and revisiting existing logic flows to make them work slightly different for some new feature. Overall my average day is productive enough that I'm overall happy enough (even if unhappy I can't code in anger as much as I want) and people in charge of judging my output seem happy enough.
I think about how careerism seems to work at a lot of places, most dev roles involve more than just programming, even if programming is the single most valuable thing you could do right now, the incentives don't align with that. It's rather annoying personally. But that's probably why the Lonesome Bottom Feeder catfish is at the bottom, and not even a salaried employee but a contractor. They can make really good money, but not always, or as much as those climbing the ladder. The incentives favor the type of "productive" that goes with broad multi-tasking, directing, and a few deep dives. Even a non-catfish non-ambitious dev can do this and advance, though of course the non-bottom-feeder invasive catfishes will do better. Do it for enough years and your average depth across a broad spectrum is deep enough that it would take a while for someone fresh to reach your level with intense focus, catfish productivity or not.
If you treat meetings, calls, socializing with your coworkers, etc., as part of "work" instead of distractions from "real work" (that you do best in "the zone"), then it's possible to be pretty productive like that too. My context switch time depends on what I'm switching to. I haven't figured out a good way to switch from deep coding -> meetings -> deep coding efficiently, but I can switch from code reviews -> meetings -> pinball -> meetings -> emails -> direction clarification... pretty well. It's improved with practice, sure. But what I find more useful is to plan around what type of day I'm expecting to have, then it's not that hard to be productive in the context of that day or week. Most days I don't even try doing any serious coding before the morning standup, so it's a great time to do other needed things, and depending on what the rest of the day is and what I need to prioritize right now I may or may not have some good coding sessions intermixed with other things. Days of pure zone are rare, which is why I cherish them (at least with positive usages, the bug-zone days are kind of bittersweet because things shouldn't be this hard and probably wouldn't be in a non-legacy system), but I don't need that to be productive. I don't even need to do serious coding as much as I want, a lot of work is just gluing things together and revisiting existing logic flows to make them work slightly different for some new feature. Overall my average day is productive enough that I'm overall happy enough (even if unhappy I can't code in anger as much as I want) and people in charge of judging my output seem happy enough.
I think about how careerism seems to work at a lot of places, most dev roles involve more than just programming, even if programming is the single most valuable thing you could do right now, the incentives don't align with that. It's rather annoying personally. But that's probably why the Lonesome Bottom Feeder catfish is at the bottom, and not even a salaried employee but a contractor. They can make really good money, but not always, or as much as those climbing the ladder. The incentives favor the type of "productive" that goes with broad multi-tasking, directing, and a few deep dives. Even a non-catfish non-ambitious dev can do this and advance, though of course the non-bottom-feeder invasive catfishes will do better. Do it for enough years and your average depth across a broad spectrum is deep enough that it would take a while for someone fresh to reach your level with intense focus, catfish productivity or not.
The dirty secret is that most of the people that can grind away for more than 8 hours in a day are producing shit that needs to be re-done by somebody that isn't grinding themselves so hard.
Yeah, that's probably the typical invasive catfish at work. It's worse when those people get promoted after fixing a fire they created, but that happens with non-grinders too, probably more correlated with political persuasion skills to push through risky and sweeping things while forcing dependence (fire fuel) by other teams. Still there are programming gods like Carmack who embrace the grind and put out good shit. It'd be fun to work on a team full of those for a while though they might not enjoy me as much when I tire of the grind.
I guess when you're paid hourly it matters, but ya, my work day is a bunch of 20 to hour long blasts of coding, interspersed with wandering around the office or bouncing on the giant yoga ball they gave me instead of a chair. Dunno how someone could keep on the screen for more than a couple hours straight.
The only place I ever actually coded for 8 hours straight was a place in which I loved the work and I actually felt valued on a day to day basis. During crunchtime (which only happened once or twice every few months) my manager would wait around after-hours so we could leave together and I wouldn't be the only one left in the building while the cleanup crew went to work. In hindsight I now acknowledge this behavior as his way of showing support even if it meant him just catching up on news and Facebook or writing boring emails while waiting for me to be done coding for the day. He taught me a lot about managing people, and in turn I taught him a lot about being on the cutting edge of our industry. This was a very small company trying to modernize itself in the face of daunting competition.
This was the best position I ever held and was my first role as a lead. The CEO did not know much about technology but seemed to have an innate trust in me that I appreciated greatly. Granted this gave me the ability to use whatever technology I wanted so I was having a lot of fun with the day to day coding. I wouldn't even eat lunch some days just so I can finish up the task at hand before sundown. Sounds horrible but was (and still is) an incredibly exciting experience.
On the other side of town, however, where I worked for Fox Studios (yes I'm calling them out!) I and the rest of the Contractor Army would be critiqued and yelled at by executive management on a weekly basis, like clockwork. Even though they gave me all the money and resources in the world, I hated coding every second I spent at that job. Instead, I spend a lot of time walking around the lot in hopes of meeting movie stars or something.
I always figured it was the domain you worked in that made it fun or boring, but I'm starting to realize it's a lot more about the environment and people you are around that can make or break your work life.
This was the best position I ever held and was my first role as a lead. The CEO did not know much about technology but seemed to have an innate trust in me that I appreciated greatly. Granted this gave me the ability to use whatever technology I wanted so I was having a lot of fun with the day to day coding. I wouldn't even eat lunch some days just so I can finish up the task at hand before sundown. Sounds horrible but was (and still is) an incredibly exciting experience.
On the other side of town, however, where I worked for Fox Studios (yes I'm calling them out!) I and the rest of the Contractor Army would be critiqued and yelled at by executive management on a weekly basis, like clockwork. Even though they gave me all the money and resources in the world, I hated coding every second I spent at that job. Instead, I spend a lot of time walking around the lot in hopes of meeting movie stars or something.
I always figured it was the domain you worked in that made it fun or boring, but I'm starting to realize it's a lot more about the environment and people you are around that can make or break your work life.
Are you doing a personal project or are you just going down a list of features that you have to implement? For a CRUD app it's fairly easy to just trudge through the list since you aren't making creative solutions or passionate about what you're doing.
I mean yea, take breaks. But when I do contracting I'll take an exactly X minute break before resuming and still work for 8 hours.
8 straight? I've done it if you don't count the lunch my wife put in front of me that I didn't remember eating. There is also some value to taking a break. I've walked away from some problems that made may head hurt - only to solve them while playing foosball.
Once I was playing foosball while the site was down. Someone walked in, quite unhappy about seeing the dev team playing when he thought we should have been fixing. Explaining that we couldn't do anything about it - ops had server issues that we could not help with. There is a time to work and a time to play. I find I'm best with 2-3 hours of work without distraction.
Once I was playing foosball while the site was down. Someone walked in, quite unhappy about seeing the dev team playing when he thought we should have been fixing. Explaining that we couldn't do anything about it - ops had server issues that we could not help with. There is a time to work and a time to play. I find I'm best with 2-3 hours of work without distraction.
Thinking about how to solve a work problem is work.
I agree. I had some of my best ideas in cigarette breaks (or, alternatively, at night when I was just about to fall asleep).
Also, going to the bathroom can do wonders if your mind is stuck on some problem. Seriously.
Also, going to the bathroom can do wonders if your mind is stuck on some problem. Seriously.
[deleted]
[deleted]
This is incredibly confusing choice of terminology, because "catfish" means to pretend to be something better, online, (or an entirely different person) than you are in person. [1]
(I bet 80%+ of American readers understand this to be the definition.)
So I thought the article would be about somehow crafting a linkedin and github profile that makes you seem like you're worth $250K, whereas in fact you are an actual imposter -- a junior programmer, for example, with less than 2 years of coding experience and in only one or two languages. Or someone who's just not a good coder and gets fired from everywhere due to not being a good coder.
I found the article interesting, but I don't like the fact that it chose a term that pretty much means the opposite of what it intended.
Really confusing.
[1] http://www.urbandictionary.com/define.php?term=catfish
(I bet 80%+ of American readers understand this to be the definition.)
So I thought the article would be about somehow crafting a linkedin and github profile that makes you seem like you're worth $250K, whereas in fact you are an actual imposter -- a junior programmer, for example, with less than 2 years of coding experience and in only one or two languages. Or someone who's just not a good coder and gets fired from everywhere due to not being a good coder.
I found the article interesting, but I don't like the fact that it chose a term that pretty much means the opposite of what it intended.
Really confusing.
[1] http://www.urbandictionary.com/define.php?term=catfish
"catfish" is a type of fish. 100% of people who have ever fished understand this to be the definition :)
I wasn't aware of that term until about a year ago. Never saw the TV show, and using that terminology didn't benefit the article.
As pointed out in other posts, the article is a tad cynical, but I draw the line at outright bashing people or making assumptions about their character (every statement would have a caveat with "some, not all").
I think with that terminology, it would be an obvious angle that would force the article into an "everyone knows this" rant, which would take away from the attempted humor and alternative viewpoint. I left a lot unsaid, but it was an antidote to saccharine posts while hopefully not coming across overly bitter (because I'm not at all).
As pointed out in other posts, the article is a tad cynical, but I draw the line at outright bashing people or making assumptions about their character (every statement would have a caveat with "some, not all").
I think with that terminology, it would be an obvious angle that would force the article into an "everyone knows this" rant, which would take away from the attempted humor and alternative viewpoint. I left a lot unsaid, but it was an antidote to saccharine posts while hopefully not coming across overly bitter (because I'm not at all).
I liked the rest of the article :)
https://en.oxforddictionaries.com/definition/catfish
The urban dictionary definition of catfish is ridiculous.
The urban dictionary definition of catfish is ridiculous.
I don't understand, you just linked the oxford dictionary giving the same definition...
(The link you wrote says
That's exactly what the urban dictionary definition says and is the meaning I referred to. Luring a company into a relationship with you based on a false/fictional profile as a programmer is what I would have thought the term would mean.
(The link you wrote says
US informal with object Lure (someone) into a relationship by adopting a fictional online persona.
‘he was being catfished by a cruel prankster’
‘a victim of catfishing’"
That's exactly what the urban dictionary definition says and is the meaning I referred to. Luring a company into a relationship with you based on a false/fictional profile as a programmer is what I would have thought the term would mean.
It's not a great simile; do you have a better suggestion? I also thought "wtf that's not a catfish" but after reading 2 sentences I had firmly updated my context.
I worked on a truly awful mess of a codebase. It was the kind of codebase through which many devs had passed, and many generations of best practices. One part was straight JavaScript. Another had some jquery. Another had backbone.js - the perpetrators were all former full time employees. The product had never launched.
I generally worked 8 hours and signed off promptly to work on my own projects. I did quality work. I viewed myself as a hired gun who was paid to do a job. In the end I was at the company longer than any of their actual full time employees (who left because they didn't like working on the crappy code or were stressed because of company politics) and was the only developer left to take the product to launch.
Employees and employers often think that contractors are vampires, and many are, but you'll find the good ones are practically immune to whatever skeletons you've got in the closet and will get the job done.