I spent a few years as a full time contractor and kind of had a chuckle at this.
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.
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 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!
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 :-(.
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.
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 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."
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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!
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.
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!)
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.
> 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.
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.
[+] [-] katzgrau|8 years ago|reply
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.
[+] [-] zeta0134|8 years ago|reply
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.
[+] [-] ENTP|8 years ago|reply
[+] [-] maxxxxx|8 years ago|reply
[+] [-] peteretep|8 years ago|reply
[+] [-] pjmlp|8 years ago|reply
[+] [-] TallGuyShort|8 years ago|reply
[+] [-] scotty79|8 years ago|reply
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.
[+] [-] majewsky|8 years ago|reply
[+] [-] nunez|8 years ago|reply
[+] [-] libertymcateer|8 years ago|reply
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."
[+] [-] douche|8 years ago|reply
[+] [-] rurban|8 years ago|reply
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.
[+] [-] Nursie|8 years ago|reply
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...
[+] [-] sqeaky|8 years ago|reply
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.
[+] [-] TeMPOraL|8 years ago|reply
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.)
[+] [-] BigJono|8 years ago|reply
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.
[+] [-] calpaterson|8 years ago|reply
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.
[+] [-] Illniyar|8 years ago|reply
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.
[+] [-] mighty_bander|8 years ago|reply
[+] [-] avenoir|8 years ago|reply
[+] [-] linkregister|8 years ago|reply
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.
[+] [-] xupybd|8 years ago|reply
:( friendships are important to everyone, this sounds like a really unhappy way to live.
[+] [-] lhnz|8 years ago|reply
[+] [-] zeamaize|8 years ago|reply
[+] [-] sbov|8 years ago|reply
[+] [-] lordnacho|8 years ago|reply
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.
[+] [-] esaym|8 years ago|reply
[+] [-] 0xdeadbeefbabe|8 years ago|reply
[+] [-] antihero|8 years ago|reply
[+] [-] richardknop|8 years ago|reply
[+] [-] andirk|8 years ago|reply
[+] [-] ShabbosGoy|8 years ago|reply
[+] [-] chuck32|8 years ago|reply
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?
[+] [-] 1234321|8 years ago|reply
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.
[+] [-] pteredactyl|8 years ago|reply
[+] [-] douche|8 years ago|reply
[+] [-] le-mark|8 years ago|reply
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!
[+] [-] halfnibble|8 years ago|reply
[+] [-] laythea|8 years ago|reply
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?
[+] [-] AceJohnny2|8 years ago|reply
> King blood-fest on the planet.
I was expecting it to be Wolfram on that second line :|
[+] [-] madiathomas|8 years ago|reply
[+] [-] paultopia|8 years ago|reply
$ 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!)
[+] [-] jperrot|8 years ago|reply
[+] [-] dizzystar|8 years ago|reply
Searching "map" was an entry into the larger joke, but not sure if it came across on the psuedocode.
[+] [-] kbenson|8 years ago|reply
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.
[+] [-] nerflad|8 years ago|reply
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.
[+] [-] linkregister|8 years ago|reply
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.
[+] [-] crusso|8 years ago|reply
[+] [-] benhardy|8 years ago|reply