Catfish Programmers
butternotes.com
butternotes.com
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.
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!
* 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!
You'll be at the next level of expertise soon!
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 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.
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.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
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.
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.
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.
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.
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.
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.
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.
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.
What? This statements are very arbitrary.
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).
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.
[0]: http://programmer.97things.oreilly.com/wiki/index.php/The_Bo...
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.
Give me profiling tools, debuggers and refactoring tools any day of the week.
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?)
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.
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."
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.
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...
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.
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.
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.)
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.
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.
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.
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.
Sometimes it is a godsend.
* 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.
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.
:( friendships are important to everyone, this sounds like a really unhappy way to live.
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 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.
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?
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.
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.
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.
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
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!
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?
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.
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.
> King blood-fest on the planet.
I was expecting it to be Wolfram on that second line :|
$ 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!)
Searching "map" was an entry into the larger joke, but not sure if it came across on the psuedocode.
Increments each element to odd.
Multiplies each number by 3 (each number is still odd)
Filters for evens then sums them.
Always returns zero.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
EDIT: 'miles up'
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.
REAL PROGRAMMERS can write FORTRAN code in any language, right? ;-)
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 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.
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.
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 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.
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.
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.
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.
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.
Also, going to the bathroom can do wonders if your mind is stuck on some problem. Seriously.
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.
(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.
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).
The urban dictionary definition of catfish is ridiculous.
(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.