Thanks for sharing. Good catch at the end. It's easy to forget this as a developer. But usually technically details are just that in the bigger picture - details. They're only important if the bigger picture is somewhat correct.
It's also said, about Moltke the Elder, that he only ever laughed twice in his life. The first time was when his mother-in-law passed away, the other time, when he saw Sweden's Vaxholm fortress.
It's absolutely true, and while he could have made a mockup showing how it would look for someone with a zip code in eg. Dallas, getting through the bureaucratic hoops to actually get feed back from those who eventually shot it down ... that's just really hard, most places. "We can't show this to customers/users/management, it's not completely done!"
It's a process problem and you can't solve it bottom-up.
You either get used to it and work to the specs, knowing they will change a lot, or you try to get closer to whoever makes the decisions. More often than not, that leads you to another company working on a different problem ...
I feel like I'm missing something in that article. Probably some historical context. Is it really about execs at Sun pranking each other by installing Sun's own flagships OS on each others' computers? Isn't that like "pranking" Satya Nadella by making him use Windows 10?
"On September 4, 1991, Sun announced that it would replace its existing BSD-derived Unix, SunOS 4, with one based on SVR4. This was identified internally as SunOS 5, but a new marketing name was introduced at the same time: Solaris 2."
I guess the execs didn't have a high opinion of their new product.
"Bye, bye, SunOS 4.1.3!
ATT System V has replaced BSD.
You can cling to the standards of the industry
But only if you pay the right fee --
Only if you pay the right fee . . ."
For context, the guy who wrote "The Worst Job in the World" email was Michael Tiemann, one of "open source's great explainers." ;) Now he's pranking IBM executives by installing RedHat Enterprise Linux on their mainframes.
Windows is meant for desktop use by managers, Solaris was never realistically meant for that sort of use-case.
So it's a bit more like replacing the BMW company car some VP at Caterpillar drives around with one of the 400 ton trucks Caterpillar itself makes. Yes it also has wheels, yes it's also a vehicle, but no, you can't really use it as a company car.
That was a lot later. Michael wrote that story in the early 90's, probably 90 or 91 while I was working there, during the transition from SunOS 4.1.3 to Solaris, when they forced all the engineers to "upgrade".
He and Gumby and John Gilmore founded Cygnus Support ("We make free software affordable") in '89, and Michael was consulting at Sun, working on supporting gcc as an alternative to the shitty AT&T C++ compiler. Remember that Sun unbundled the C compiler from Solaris and started charging for it, and AT&T charged for their shitty C++ compiler too.
The Free Software Community Puts A Free Compiler Back In Solaris 2
Sun Microsystems, Inc. decided to unbundle the C compiler from their latest operating system, Solaris 2. Sun users were extremely upset to lose what they saw as an essential component of the system software. Faced with dramatic increases in licensing fees, early Solaris 2 users turned to free software for a reasonable alternative.
Spearheading the effort to port the Free Software Foundation’s GNU C compiler was Palo Alto based Cygnus Support, a company that specializes in providing commercial support for free software. To fund the development effort, Cygnus appealed to the early adopters of Solaris 2. They offered a year of technical support for up to 5 users, and a commitment that the compiler would ship with Solaris 2, in return for a prepaid fee of $2,000.
To insure wide distribution of the free compiler and debugger, Cygnus negotiated with SunSoft, Inc. to make the GNU C development tools available on CDware. CDware is a free CD-ROM available from Sun and shipped at no cost to over 90,000 Sun users.
It's an amusing story, I've seen this countless times as well. I think what finally sunk in for me was that if you're focused on saving money or efficiency on small projects then the upper limit of benefit to the company is less than the budget for the project. Instead if you focus on optimizing for the market, the profits can be unbounded essentially, and any wasted money to get to market is simply part of the learning process.
And if you're the contractor having to run around as the plans change, well just make sure you get paid enough :)
As contractor I like jobs where I can basically recommend “Just don’t build this at all.” For example the young startup that wanted credit card payment and automation for essentially a two digit number of invoices per year for a target market where bank transfer would be much more common. Replaced with an excel sheet. Customer happy. I don’t want to build crap just for the money that’s in building crap. Let me actually add value.
Yeah same here, what’s strange is you have to explain that to clients too. They don’t get you’re contracting because you like to actually do things and helping them is part of the reward. Otherwise you’d just be an employee.
Probably no but they surely built goodwill with that company and as a result can help them build a good reputation. This is often overlooked but people will remember that.
Or they could just be satisfied with doing the right thing, rather than trying to extract as much money as they could.
That is pretty awful. But you know, and maybe this is just me being too fatalistic due to what’s happening in my own professional life, but most of what we do is a waste of time in some sense.
Just shovel the shit, get paid, and move on. They want it changed? great, change it. They want a form that does something stupid, fine, build it. A lot of people spend their work day ringing up plastic crap that people don’t really need, or whatever. Which is to say it could be worse.
Of course part of what sucks about this story is that the author failed to do the “get paid” part correctly, but I’m speaking generally. I just can’t get too attached to outcomes anymore.
It’s not miserable really, I just sense the pointlessness in it, and in what happens in most of corporate America. Where I work is considered rather desirable actually, here and elsewhere. I’m well compensated which is the point of a job after all.
I think there is wisdom in acknowledging that you’re there to shovel the shit, and then shoveling the shit, and leaving it at that.
However there's a case for fixed pricing and it can work to your advantage: Think of a difficult task or problem that you already solved in similar cases - maybe you already have the heavy foundation of that work ready as a template, maybe you automated complex, repeating steps. Or just think of a simple task that has huge value for your customer. Pricing shouldn't always depend on how long it takes you to finish a project.
Or if you really want to play the fixed price game, better add a _large_ buffer which you may keep should the project miraculously complete on time. You transfer the risk from the client by doing fixed price work and risk is expensive.
And of course, _every_ client change, goes through a process that evaluates it for additional cost that gets added to the bill. I think this change process is a considerable money earner for consultancies.
But yeah, personally I always just charge a day rate.
This... this is just my life right now. Get a contract, spend all of my time doing anything other than actually accomplish anything, and then after wasting time adhering to project requirements that don't make sense, wind up delivering something that could have been done in 10% of the time if people listened to me at the start of the project.
That assumes software developers think the problem is best solved by developing new software - which quite frequently isn't the case!
Oh how I wish we could stop reinventing this same stupid wheel badly. And change the "wants" framed as requirements into something more reasonable, so that we could get away developing less bumpy wheels, perhaps even use one off the shelf.
At my previous place, after several times where the wheel was re-invented I asked one of my senior guys what did he think he got paid for.
Perhaps unsurprisingly the answer was to design features, write code, review code and advise support. Whether any of this delivered any value to the company was, seemingly neither here nor there and he'd held my position before I joined the company, so it's not like he never had to think about these things or at least he should've thought about those things but the code would testify that he hadn't.
I do think it's a bad thing. In my experience the best developers are those who view new software as a last resort (or rather a second-last resort, with manual work being the last resort).
> Oh how I wish we could stop reinventing this same stupid wheel badly. And change the "wants" framed as requirements into something more reasonable, so that we could get away developing less bumpy wheels, perhaps even use one off the shelf.
And in keeping with the spirit of the article charge murderous fees to help people with their "Big Data" Cassandra installations, only to find out after weeks of wading through a management quagmire that the data in question can be stored in a few KB text file.
"Big Data" doesn't mean "makes Excel slow down" or "needs to scroll in Excel" :) If you can fit it on a thumbdrive you can buy from a Walmart, it's probably not 'big data'.
This really is true, I worked on a project where we were meant to be getting hourly files into a data lake, the files so small we couldn't reach the recommended size of 256mb per file (compressed parquet in azure adls) - the files were like 1 mb each - a years worth of data was tiny and the processing overhead ridiculous
This goes for so, so many things I've seen where it's not even big data, but crap like some small part of their total dataset being a graph (unlikely to ever go beyond a thousandish nodes for any given connected set, and even that'd be unusually high, and certain to be sparsely connected to boot) so of course we have to use a hipster-ass graph db adding thousands in development costs and making the whole thing harder to work with and (demonstrably—this wasn't the first project they'd made this mistake on) less stable eyeroll.
Starting a new project? You almost certainly don't need something other than 1) files (yes, seriously), or 2) SQLite (yes, seriously), or 3) Postgresql or some other multi-paradigm, capable SQL DB. If the former two, please also consider whether you even need a f*cking server or are actually writing something that ought to be desktop/mobile software. That's another expensive, feature-delaying, and UX-harming mistake I've seen.
I started a new job where I was not officially a programmer and my machine was locked down so that I could use basically nothing except Microsoft Office, and after a couple of months, I have taught myself to do nearly any sort of data processing I previously did with Linux, Oracle, Perl, Selenium, etc. using Excel, Access, and VBA. Obviously, this doesn't involve that much data, but my previous job was really not "big data" either and they paid for all sorts of expensive licenses.
I'm enjoying myself much more than I used to, because I've escaped the red tape of development and get to solve problems that matter to nontechnical people without intermediaries predigesting the requirements.
If I was starting a business, I would definitely always try to do almost anything with Excel and Access first before deciding to invest in an industrial strength solution whether Postgres, Oracle or "big data".
>wind up delivering something that could have been done in 10% of the time if people listened to me at the start of the project.
I felt that way until I eventually got to a point where people did listen - and it turned out to be false. I underestimate the effort required on first glance and I oversimplify things in hindsight. Also I'm a developer - not a business guy - I can guess a lot of things on the requirement side but a lot of it is outside of my domain. This is something that I have to be aware of now when I'm in a position to give such estimates.
Don't get me wrong - I think there's a lot of room for improvement in almost everything I worked on before and after me - but that gut feeling of how I could have done things was never on point for me. With the article in question - too many people involved in the decision - no way to know the final result for sure until people see it have a bunch of meetings, see the iterations and decide on this - rarely do you have the person with deciding power know/understand these things clearly from the start. And you need to account for bureaucracy BS time-waste - it's just a fact of life when dealing with such clients.
I think most of the impediments are intentionally created to hinder projects so that nothing looks to easy or successful. This may help explain why some PMs or product owners inflate the product features when internally advertising the effort, that way if other people throw up roadblocks they are less likely to impact a core feature.
I suspect something similar. I had a project which had a team of developers for six months; we didn't do anything the first four months (I spent a lot of time on HN during that time!). After those four months, we discovered that during the last month, being December, we were not supposed to release anything (as it might endanger the end-of-year runs). We did the entire thing in two weeks and then deployed it in the remaining two (deploying was a nightmare).
At some point, we discovered that the team lead wanted to be promoted to manager so he needed a reasonably-complex-but-actually-simple project as a "win".
This has been my experience and it might be sane. The 90% went on project/requirements discovery. Remember that you are doing this through several people, so it's multi-dimensional and once you leave 2/3 dimensions things start to get really complex.
It's pretty much what's happening on my assigned project. It's a legacy app created in the 90s... most of the time spent is just things that takes 1-3 days but due to the constant tweaks and re-tweaks it can take months. In a personal sense it doesn't affect me. I do the work they require me to do and get paid for it. Professionally and personally, I'm a huge mess because I'm frustrated on how bad is the decisionmaking. I feel I'm just wasting, and even though I'm paid for it it just doesn't feel like I'm doing anything with my career. Sigh.
I'm burnout and have been questioning myself after 2 years servicing clients in the company I'm in if I'm good enough for other roles (using as example) promoted in HackerNews, or whatever job portal.
When I spend so much time idling by and letting that frustration build up... I just start questioning if I'll be able to do other roles and not fail the team or whatever company I'll be working for because of how dormant I am.
It's not like I knew a lot. I don't consider myself to be super talented, just the average guy trying to make it out there but yea... I need to look into moving on.
Invest time into thinking about and listing specific things you've learned (technical, but also organizational, managerial, etc.) from maintaining this horrible legacy system.
This list will show you that it hasn't been a complete waste of your time, and it will show future employers that you're thoughtful, observant, respectful of your own time, and healthily critical.
My advice is to interview a couple times (with companies you don't mind missing out on), find out what you are missing and work on side projects that interest you. Then interview again about 6 months later. There is nothing like interviews to set your mind straight. Competition and hard questions seem to energize my "survival" instinct.
...doing something hard and outside of your comfort zone I guess is what I am recommending.
I was in the same situation as you at my previous job, feeling like I wasn’t learning anything because I was working on a legacy system where every design and business decision made was pure insanity
After five years at this place I finally got my shit together and applied for a job
I spent the job interview asking pointed questions about their infrastructure and how they ran their business and then I contrasted their way of doing things with my old job and explained why their way was so much better
Turns out I was learning! And learning how NOT to do things carries some value
Sometimes the desired result is not known ahead, at project start, and twisting and turning is part of the process of (hopefully) ending up with something that people are happy with. It's just part of human nature and needs to be embraced. You just ensure you are paid for it.
This is something every freelancer have seen. Who ever introduces you to the job rarely knows what the end-product should look like and it really proves the value of creating a minimum viable product, showing it to customer and pivot from that to where you might need to go. It this case the MVP would have been the final product.
> Prudential Real Estate is a franchise operation. Prudential does not actually broker any real estate. Instead, a local franchisee pays a fee for the use of the name and logo and other services.
I don't know how contracting works, but for corporate project the rule is always "follow the money", then once you figure out the money flow, only then do the requirement gathering bit.
Doing it in the opposite order will result in tears.
My shittiest project was a hostile takeover from another development team.
In the interview, the manager told me a bunch of BS that turned out to be completely false: that it was a new project, that lots of new development was expected, that there where performance challenges to be tackled.
When I got there, I found out on day one that the goal of the project was to take over the code base from an existing development team, with which the customer had lost trust because among other things they refused to use their new shitty trouble ticket system (which was awful), and instead insisted in using JIRA.
Also, they had a server running in Tomcat that they didn't want to migrate to Websphere.
Turns out that we didn't even have access to the code, until we accidentally found that the SVN repo was listed in an infrastructure powerpoint, and we did have a VPN connection set up.
We were at the taking over consulting firm offices and not at the customer, reverse engineering the existing 7-year-old codebase without any assistance from the development team, which didn't even know that they were getting replaced.
After months of reverse engineering and producing useless documentation so that the client manager could say in some meeting that the system was well documented, we ended moving in and mostly doing production support instead of development.
Our managers were afraid that we broke something, so they did everything to make sure that we didn't spend our time coding.
After a few months, I just asked out because it was not development work and this type of work was actually harming my career and even had my consulting manager actually shout to me on the phone and tell me that he would blacklist me at his company.
Software consulting is some of the shadiest businesses out there, beware.
The amount of lies that gets told to candidates just to get them signed at the dotted line to contracts without exit clauses (which was the case with me), the use of outdated job descriptions, the lack of information that you have about the actual job even if you ask a lot of questions in interviews, you really never know what you are getting into until day one.
Here is a tip from what I have learned: ask a ton of questions about what the job will actually be, if they answer evasively or strangely seem like they want to avoid the questions and move on to other aspects of the interview, that is a huge red flag.
Yes its insane LOL Managers were non-coders themselves, and they looked at developers with suspicion.
This happens in a lot of projects, where developers are almost treated like children or assembly-line workers.
I realized through small hints and queues over time that the goal was to take over the maintenance of the project and make sure that we could fix things if something broke, but not add any new features.
They even had a management term for what we were doing. They called it KIR - Keep It Running! LOL
yes but happens a lot - if you dont change it, it won't break (expept it will, every time because the reason you don't change it is because it is crap in the first place)
Higher pay than consulting its hard, a consulting job pays usually almost twice as much as a permanent job.
I prefer it to permanent, because besides the monetary aspect you can also get into new projects just starting out more often, and that is were you learn more when compared to maintenaince projects.
What type of opportunities would you recommend other than consulting?
Contracting is different from consulting. As far as I understand when you are consulting you are a permanent employee of a consulting company that assigns you to various projects. When you are contracting you work for a temporary period of time exclusively for a client until your contract ends or you find better opportunities.
The first case is paid double of the permanent to the consulting company, but the employee of the consulting company is lucky if he gets as much as a normal permanent. A contractor on the other hand gets paid much more than a permanent, especially counting the less taxes that he needs to pay. There is a 3rd option when you actually own the consulting company, but then it’s up to you to find clients and if needed additional resources to assign to the various projects, but in that case you may be paid even more than contracting if you have no down time between projects.
I guess it depends from the country and the type of contractor.
In UK, with a limited company, you pay less taxes (at least until next April). If you are under an umbrella company you will pay more taxes because you’ll be paying all the taxes of a normal employee plus the taxes of the employer. No idea if it is different in US and other countries honestly...
It’s a very good question, and a long story. As far as I know still no one has a certain answer.
The back story is that in April 2017, if I remember correctly, all the contractors that worked for public companies were forced to be under the IR35 rule. This rule, in short, tells that the contractors are equiparable to permanent employees.
So they had to pay taxes as permanent employees, without the perks, like paid holidays, sick days and so on.
This caused a quite massive loss of public contractors, understandably.
From April next year they are implementing the same schema in the private sector, with the difference that it will be up to the employer to declare who is inside IR35 and who is not.
The mainstream theory is that employers will start putting everyone under IR35 to avoid problems with HMRC. Even if this won’t be the case at the beginning, after the first couple of high visibility cases in which hmrc punishes the employers for some wrong IR35 classification, all the others would want to avoid the risk and headaches and will classify everyone inside IR35.
We’ll see next year how it turns out, but I’m not very optimistic. Luckily for now I’m shielded, but I’m paying an eye watering amount of taxes...
But if you're self-employed (or operate a business that's a sole proprietorship) you can deduct your expenses (equipment, rent on your home office, etc.) from your taxable income. In the U.S., you attach "Schedule C" to your federal tax return to do this:
A contractor is effectively a non-permanent employee: someone you hire for a fixed period because you have irregular work load and you need some extra people temporarily. I say effectively a non-permanent employee, but it's really skirting the edge here: if the relationship is too much like an employee, then the contractor is an employee for tax purposes.
A consultant is someone you hire for their expertise. They're a specialist; they tell you what you should be doing, rather than doing work you specify.
IT contractors are also usually employed by contracting companies that take care of accounting and other overheads, and if they do things like marketing and referral, they'll eat a significant chunk of the fees too. I don't think there's a significant difference in organizational structure between contractors and consultants in this way. It's mostly that consultants address the problem at a bigger distance, and are more likely to be drawing up the plan, rather than working on the execution.
ok, it makes sense, but then the consultant is kind of the 3rd option in my previous post but his job is to advise rather than actually do all the work, right?
could you elaborate on the negative effects on your career? were you a contractor or an employee? and why would someone blacklist you specifically? how was that consulting manager related to the project?
i mean as an employee, if i get put in a hard position, sometimes the only choice is to quit, so, in that case, the CV would have an entry that you would not look back at to happily, but other than getting out as fast as you could why would being stuck in such a situation harm your career?
Yes sure, already after a few months doing production support and reverse engineering instead of coding, you start getting questions on interviews about why are you not coding lately anymore.
This was a bad look, because hiring managers want active developers for coding positions. I ended up not even mentioning that the position did not involve much coding on later interviews, I left after 6 months.
You are put in a tough position because you will have an entry of 3 to 6 months on your profile, which is generally a red flag for hiring managers as it's too short.
An entry with a full year or more will not raise any eyebrows, but 3 months will. Also, because you leave against their will, they won't give you references to the next jobs.
I did end up leaving it was a real nightware, and never looked back, but to this day I feel that I was flat out lied to on the interview about the job content.
In other interviews at other places, I was left out critical details, like for example that the team is moving to another city in two months, and you are expected to go with them.
So this why I say, you never know what you are getting into with software consulting, it's a shady business.
With the high turnover rates and the difficulty to find developers, hiring managers are incentivized to embellish otherwise mundane positions in the interview process, leading to unmotivated staff and further turnover.
Several 3 months stints are a problem. One, bookended by reasonable work, is a filter. If a company is overly concerned with one, they just want a skill hire, which may or may not be your target.
You can describe the stint in several ways, such as "the strategic direction the consultancy took was away from software and into project management early in the project cycle. My personal strengths lie in..." or some such.
> You are put in a tough position because you will have an entry of 3 to 6 months on your profile, which is generally a red flag for hiring managers as it's too short.
As an employee, probably. As a contractor, I prefer short contracts (1-3 months is short, 6 months is average) with a clear deliverable. If I wanted to just "sit around and do whatever" I'd get employed.
agree, it's all a matter of how you look at it. in my CV i don't even make a distinction between contracting and employment. i have even been contracting with and was employed by the same company at different times.
I've been becoming less cynic about workplace bosses and their decisions. I'm not really talking from raw workplace experience, but from noticing things I've read. I think a boss order comes from a perspective that is _probably_ right. They have an understanding that a developer _might_ not have yet, their instinct could be accurate, maybe most of the time.
I think anyone who has done any consulting with a big organisation probably has one of these stories. As one of the other commenters says, if the end result is something that the client is happy with, and they actually pay you, you should basically consider this a success!
I spent six months building a single-page app (back when that was still an exciting sounding thing) for a major US financial institution; by the time we actually delivered it, the result was so watered down from the initial proposal that I could've just taken some screenshots from what my designer had produced six months earlier and put them in a PowerPoint deck and said "Done!" - because this was, in fact, what the VP at the company ended up doing, except they were screenshots from the web app we built that no one other than the VP himself ever used.
On the plus side, I became good friends with the VP and the project paid off a significant chunk of the mortgage on my first house.
The whole point of all of these stories is funny/sad misallocations of resources. The "real problems" thing is a completely unrelated discussion. Not sure why you'd want to weave that in.
He's weaving it in because the parent called it "a success", which is only true from your individual perspective, but not from a societal one. And some people want more from what they're doing than just personal gratification.
I can confirm that I both got paid handsomely (especially for the second phase of the project where we were on a retainer and literally did one day of work over the course of three months, barring a couple of phone calls) and that I felt very little satisfaction or gratification at the end of it, especially when the whole thing we had built was eventually rebuilt by a different offshoring company using a much clunkier technology stack without so much as a glance at our code.
I stand by my original assessment that, from the perspective of both the client (everyone was happy with the end result) and my consultancy (we delivered work and we got paid), it was a success.
I agree that our definition of success should have a strong societal component. However, if you expect societal benefit from every action, including actions heavily dependent on something like the whim of a consulting client, you may be faced with a lot of anxiety when you inevitably fall short, anxiety which may ultimately hamper your later individual capability to achieve societal benefit.
When it comes down to it, we're not paid to code. We're paid to solve problems with code and if paying you $75/hr as a contractor to build me three webpages with CI/CD capabilities is it, then off you go.
Yeah, if I paid a carpenter to build me a chair, then decided I wanted a stool, then ended up with a footrest, I would be really happy with him if he delivered all those things so I could try them and make up my mind. It could've been that the agents saw it and said "It's great but send me an email when they click the link", and then the development would have gone in that direction.
As an aside, I sometimes have to play UX designer when there is no one qualified available, and I've used every wireframing tool in the market trying to find something that allows me to create UIs as quickly as I can think. A few weeks ago I gave up and in frustration I put together a quick powerpoint so the product team could work on it themselves. It turns out PP is exactly what I was looking for! I found that all the other tools required a lot of setup and configuration that slowed me down, and powerpoint is so simple that you can just start plopping squares down on the page and put a few links in-between slides. I think the real gain for me is that most products I work on end up being data grid heavy, and creating tables in balsalmiq/whatever is always a nightmare.
I've had a lot of luck using Balsamiq as a wireframing or mockup tool. Quick to get into and edit, and clearly meant to be a UI mockup and not a pixel perfect representation of the final product. It eliminates a lot of wasted time on bikeshedding and lets people focus on the layout and flow.
Not me, but one of my favourites would be when a guy joined our team. We were an agency and he’d been hired by the client to eventually take over. On the first morning I walked him through the codebase and showed him how it all worked, how to extend it etc. After a while I said “any questions?” He replied, “yeah, just one - am I meant to be a developer?”
Turned out that when the startup had brought him in as CTO they failed to mention that he was eventually going to be the sole developer.
To his credit he just kinda sucked it up and got on with it. I was happy because eventually I didn’t have to work on it anymore. Surprisingly, all the money they wasted on buying rack servers and Oracle enterprise licences didn’t net them more than 10 visitors a day and it feel apart. Once it all went pop, him and I crossed paths on other projects too, got to trade stories about the absurdity of it all.
Accepting a job offer based on a false representation. Usually by offering you an inflated title and promising responsibilities and opportunities you won't actually have.
My buddy quit a senior developer role day 1 at Walmart labs because they sat him down and presented him with the task of doing nothing but technical writing.
I worked there, I find this story hard to believe, though I left after Dion/Ben left, and the paypal mafia came in with their button downs tucked into their khaki's, and Jira became more important than actual technology, and the culture was taking a nosedive fast.
Still, I can't imagine the culture falling that far in two years. Their was tons of meaty dev work being done. And day 1? Maybe they were just trying to ease him into the team? This might have been an effective Mr. Miyagi type move to help him get a greater understanding of how all the pieces work together.
This story smells bad, I would be interested to hear more details.
There was tons of exciting work being done, apparently. Lots of promise of opportunities to plug away on a hot react frontend, scores of talented teams that sort of thing. I'm sure it is happening like that.
But they were plugging holes as fast as they could with contract recruiters that were throwing whatever would stick. I didn't even get to meet my team before I had an offer in hand.
From mine and his experience, whatever department that was (an ecommerce frontend), seems chaotic, with massive turnover.
I just left a job that amounted to this. I stuck around because I went to work with a good friend who's off-the-charts good at what we do. He lasted three months after I joined and I was gone the week after.
I've had the opposite happen! Early in my career, being brought on as a low-paid frontend developer, only to be stuck as de facto CTO on a spin-off company. Infra, development, hiring, travel, the whole bag.
Still accepting advice on how to negotiate a 100% raise.
Imagine a Controll Software - not written in StateDiagrams, but in either a sort of assembler, a drag&drop connection language or similar. Imagine parallel execution without correct communication handling (usually no semaphores etc.).
Imagine massive mountains of copy pasted code (although not fail of the plattform, it encourages creating classes- called fb).
Imagine some in-over-his-depths guy in panic adding and adding to this mountain of garbage, until the project gets critical and you are called.
Then you get to rewrite the mess ("Its almost done") while a men-choir of suits stands behind you, breathing in your neck till the fungi grow ("You are aware this factory has x-parts in storage and will stand still if you dont provide fix in time of x per hours").
In theory this is all super easy, its just, the coding culture is still in the late 80s. Thus its hell.
I can say, as a seasoned web apps outsourcing contractor, there are two sides of the medal.
The bright side: clients usually come to me with just an idea, plan or sketches, almost all of my projects were built from the ground up, I totally technically owned them. This is a delight for any coder (and I code a lot, not just manage the team).
The dark side: many startups and green business ventures fail, and the failure rate is around 80%, even larger in the longer run. And I do the apps from the ground up, nurture them.. but sometimes I feel myself a gravedigger.. out of any 10 projects maybe 2 or three are still there after a couple of years.
After working in a web agency for years, my number 1 red flag that the project is going to go badly is the quality of their current website they’re hiring you to fix/replace.
If it’s solid but just a bit old or needs more features, you’re fine. But, if it’s crap, look out.
The quality or lack of is never down to the the people who built it (unless it was by the MD’s nephew or something), especially if the client blames them for it.
It just shows they can’t run a project properly and whatever you end up with will be just a slightly newer pile of crap. And they’ll slag you off to the next lot.
Number two red flag is if they say at any point “You tell us, you’re the experts!” This can be translated to, “We don’t know what we want but we’re going to reject whatever you say anyway.”
> Number two red flag is if they say at any point “You tell us, you’re the experts!” This can be translated to, “We don’t know what we want but we’re going to reject whatever you say anyway.”
I disagree with this being a red flag. That's exactly why I hired someone to build me a small website. It's not because I don't know HTML / CSS / JS; it's because I'm bad at (visual) design. I wanted someone who knows what they're doing to use their expertise and give me a good product.
That’s great, you know to hire an expert and let them get on with it.
The problems start when the client either can’t or won’t explain what they want, then gets upset that what you produce doesn’t match what’s in their heads. At that point they start trying to undo every decision and things go south rapidly.
One company I worked for had a great website. One of my coworkers worked on it as his baby and took great care of it. Rest of the software stack was a dumpster fire.
One other coworker came on board because they thought "no bad company would ever have a bad website". The guy who hired him left a week after he joined. One developer left every week for four weeks afterwards.
Website quality is a weak signal; I'd say if a website didn't have any errors or warnings in $BROWSER DevTools, or made a mention of not pasting JavaScript here or having an explicit "oh hey you're a developer we're hiring", then that's good. Otherwise keep asking questions.
Do you think this is why developers need to be made aware of user journeys? In my experience, just spending some time on thinking through the user journeys has done wonders to my understanding of features.
Edit : The article doesn't mention anything about user journeys. Hence the thought :-)
In an ideal world yes - but in some situations its just not practical. For example, I once worked on a (large) project for a company I worked for where we were the customer and developers were out-sourced about four levels deep - they weren't even clear as to who the top level customer was let alone what the user journey was.
As he said he was green, I think this really shows that early on, young developers do not always understand the importance of requirements gathering and problem understanding.
Just yesterday, a junior developer from my team came to me about a request to generate some output from historical data. I went back to the business side and determined it was just a simple switch of several columns in the input data to get the results.
My junior developer at first thought it was some monumental problem that was going to require a lot of work.
I'm a noob when it comes to coding but I worked a technical job with customers for 20 years before changing paths.
I was in a position where I joined a place as the "new old guy" and several new college grads.
One day the president of the company comes to me and asks "You know the questions to ask! Some of our experienced guys don't."
It takes a lot of effort for two people or groups to form an idea and be on the same page, understanding "all" doesn't mean *, thinking of roadblocks before you get there (seeing them coming), softly working around those roadblocks, helping frustrated people, offering alternatives without going off the rails, listening closely to find out what is REALLY important and etc. I think that stuff just comes with experience working with humans.
My own experience makes me think everyone should be required to work some form of technical support for a while ;)
304 comments
[ 6.0 ms ] story [ 279 ms ] thread1) save significant amount of time ahead
2) give your customer time to identify what they really want
3) help you iterate quickly on newer versions. If something doesn't work, it's easy to throw stuff away
Old army observation. No Battle Plan Survives First Contact With The Enemy. Thus the sooner you get that over with the better.
Mike Tyson said it better: https://i.imgur.com/Gy9TWiq.jpg
Just wanted to add a source: https://en.wikipedia.org/wiki/Helmuth_von_Moltke_the_Elder
https://en.wikipedia.org/wiki/Vaxholm_Fortress
It's a process problem and you can't solve it bottom-up.
You either get used to it and work to the specs, knowing they will change a lot, or you try to get closer to whoever makes the decisions. More often than not, that leads you to another company working on a different problem ...
http://www.art.net/~hopkins/Don/unix-haters/slowlaris/worst-...
I guess the execs didn't have a high opinion of their new product.
For context, the guy who wrote "The Worst Job in the World" email was Michael Tiemann, one of "open source's great explainers." ;) Now he's pranking IBM executives by installing RedHat Enterprise Linux on their mainframes.
https://en.wikipedia.org/wiki/Michael_Tiemann
So it's a bit more like replacing the BMW company car some VP at Caterpillar drives around with one of the 400 ton trucks Caterpillar itself makes. Yes it also has wheels, yes it's also a vehicle, but no, you can't really use it as a company car.
If McNealy or Zander was running something else, that would have been the exception.
He and Gumby and John Gilmore founded Cygnus Support ("We make free software affordable") in '89, and Michael was consulting at Sun, working on supporting gcc as an alternative to the shitty AT&T C++ compiler. Remember that Sun unbundled the C compiler from Solaris and started charging for it, and AT&T charged for their shitty C++ compiler too.
Maybe Gumby can provide some more context!
https://en.wikipedia.org/wiki/Cygnus_Solutions
https://news.ycombinator.com/item?id=1641664
http://www.h-online.com/open/features/GCC-We-make-free-softw...
http://www.toad.com/gnu/cygnus/index.html
Free Software Report, Volume 1, Number 1, 1992
http://www.toad.com/gnu/cygnus/fsr/volume1.1.ps
The Free Software Community Puts A Free Compiler Back In Solaris 2
Sun Microsystems, Inc. decided to unbundle the C compiler from their latest operating system, Solaris 2. Sun users were extremely upset to lose what they saw as an essential component of the system software. Faced with dramatic increases in licensing fees, early Solaris 2 users turned to free software for a reasonable alternative.
Spearheading the effort to port the Free Software Foundation’s GNU C compiler was Palo Alto based Cygnus Support, a company that specializes in providing commercial support for free software. To fund the development effort, Cygnus appealed to the early adopters of Solaris 2. They offered a year of technical support for up to 5 users, and a commitment that the compiler would ship with Solaris 2, in return for a prepaid fee of $2,000.
To insure wide distribution of the free compiler and debugger, Cygnus negotiated with SunSoft, Inc. to make the GNU C development tools available on CDware. CDware is a free CD-ROM available from Sun and shipped at no cost to over 90,000 Sun users.
And if you're the contractor having to run around as the plans change, well just make sure you get paid enough :)
Or they could just be satisfied with doing the right thing, rather than trying to extract as much money as they could.
Just shovel the shit, get paid, and move on. They want it changed? great, change it. They want a form that does something stupid, fine, build it. A lot of people spend their work day ringing up plastic crap that people don’t really need, or whatever. Which is to say it could be worse.
Of course part of what sucks about this story is that the author failed to do the “get paid” part correctly, but I’m speaking generally. I just can’t get too attached to outcomes anymore.
I think there is wisdom in acknowledging that you’re there to shovel the shit, and then shoveling the shit, and leaving it at that.
If tv didn't exist, people would be more impressed with you for inventing blurry 405 line b&w than high definition colour.
The latter makes it look easy, the former gives them some inkling that it's a technically difficult task.
They'll be more grateful and impressed as a consequence.
But I can also tell from experience that fixed price, more often than not, doesn't work out so well.
And of course, _every_ client change, goes through a process that evaluates it for additional cost that gets added to the bill. I think this change process is a considerable money earner for consultancies.
But yeah, personally I always just charge a day rate.
The dream of all software developers.
Oh how I wish we could stop reinventing this same stupid wheel badly. And change the "wants" framed as requirements into something more reasonable, so that we could get away developing less bumpy wheels, perhaps even use one off the shelf.
Edit: I don't think is a bad thing and I am prone to it myself !
At my previous place, after several times where the wheel was re-invented I asked one of my senior guys what did he think he got paid for.
Perhaps unsurprisingly the answer was to design features, write code, review code and advise support. Whether any of this delivered any value to the company was, seemingly neither here nor there and he'd held my position before I joined the company, so it's not like he never had to think about these things or at least he should've thought about those things but the code would testify that he hadn't.
Sadly, this is pretty common
We'd be out of many jobs if this happened.
Or maybe that time & money could be spent on something else, it's not like we're running out of things to do.
[0]: https://en.wikipedia.org/wiki/Cassandra "Cassandra was cursed to utter prophecies that were true but that no one believed."
Starting a new project? You almost certainly don't need something other than 1) files (yes, seriously), or 2) SQLite (yes, seriously), or 3) Postgresql or some other multi-paradigm, capable SQL DB. If the former two, please also consider whether you even need a f*cking server or are actually writing something that ought to be desktop/mobile software. That's another expensive, feature-delaying, and UX-harming mistake I've seen.
I'm enjoying myself much more than I used to, because I've escaped the red tape of development and get to solve problems that matter to nontechnical people without intermediaries predigesting the requirements.
If I was starting a business, I would definitely always try to do almost anything with Excel and Access first before deciding to invest in an industrial strength solution whether Postgres, Oracle or "big data".
Edit: Clearly I am in an optimistic mood this morning.
I felt that way until I eventually got to a point where people did listen - and it turned out to be false. I underestimate the effort required on first glance and I oversimplify things in hindsight. Also I'm a developer - not a business guy - I can guess a lot of things on the requirement side but a lot of it is outside of my domain. This is something that I have to be aware of now when I'm in a position to give such estimates.
Don't get me wrong - I think there's a lot of room for improvement in almost everything I worked on before and after me - but that gut feeling of how I could have done things was never on point for me. With the article in question - too many people involved in the decision - no way to know the final result for sure until people see it have a bunch of meetings, see the iterations and decide on this - rarely do you have the person with deciding power know/understand these things clearly from the start. And you need to account for bureaucracy BS time-waste - it's just a fact of life when dealing with such clients.
At some point, we discovered that the team lead wanted to be promoted to manager so he needed a reasonably-complex-but-actually-simple project as a "win".
> I'm a huge mess
> I feel I'm just wasting
> doesn't feel like I'm doing anything with my career
Sounds like it does affect you in every sense.
You should probably try to adjust that, before you burnout not just for that specific job but your carrer in general
When I spend so much time idling by and letting that frustration build up... I just start questioning if I'll be able to do other roles and not fail the team or whatever company I'll be working for because of how dormant I am.
It's not like I knew a lot. I don't consider myself to be super talented, just the average guy trying to make it out there but yea... I need to look into moving on.
This list will show you that it hasn't been a complete waste of your time, and it will show future employers that you're thoughtful, observant, respectful of your own time, and healthily critical.
...doing something hard and outside of your comfort zone I guess is what I am recommending.
After five years at this place I finally got my shit together and applied for a job
I spent the job interview asking pointed questions about their infrastructure and how they ran their business and then I contrasted their way of doing things with my old job and explained why their way was so much better
Turns out I was learning! And learning how NOT to do things carries some value
exploring the design space and iterating until you end up with a product that makes the customer happy
and
endlessly reworking decisions every time the next "stakeholder" in the customer's org sees a part of the bikeshed that they have an opinion on
One is a skill-engaging and -enhancing professional project. The other is the road to burnout.
Reminds me of the Battlechess duck, point 5 here: https://blog.codinghorror.com/new-programming-jargon/
I don't know how contracting works, but for corporate project the rule is always "follow the money", then once you figure out the money flow, only then do the requirement gathering bit.
Doing it in the opposite order will result in tears.
In the interview, the manager told me a bunch of BS that turned out to be completely false: that it was a new project, that lots of new development was expected, that there where performance challenges to be tackled.
When I got there, I found out on day one that the goal of the project was to take over the code base from an existing development team, with which the customer had lost trust because among other things they refused to use their new shitty trouble ticket system (which was awful), and instead insisted in using JIRA.
Also, they had a server running in Tomcat that they didn't want to migrate to Websphere.
Turns out that we didn't even have access to the code, until we accidentally found that the SVN repo was listed in an infrastructure powerpoint, and we did have a VPN connection set up.
We were at the taking over consulting firm offices and not at the customer, reverse engineering the existing 7-year-old codebase without any assistance from the development team, which didn't even know that they were getting replaced.
After months of reverse engineering and producing useless documentation so that the client manager could say in some meeting that the system was well documented, we ended moving in and mostly doing production support instead of development.
Our managers were afraid that we broke something, so they did everything to make sure that we didn't spend our time coding.
After a few months, I just asked out because it was not development work and this type of work was actually harming my career and even had my consulting manager actually shout to me on the phone and tell me that he would blacklist me at his company.
Software consulting is some of the shadiest businesses out there, beware.
The amount of lies that gets told to candidates just to get them signed at the dotted line to contracts without exit clauses (which was the case with me), the use of outdated job descriptions, the lack of information that you have about the actual job even if you ask a lot of questions in interviews, you really never know what you are getting into until day one.
Here is a tip from what I have learned: ask a ton of questions about what the job will actually be, if they answer evasively or strangely seem like they want to avoid the questions and move on to other aspects of the interview, that is a huge red flag.
that's like hiring football players and not letting them on the field out of fear they'll score for the other team.
please write a book!
This happens in a lot of projects, where developers are almost treated like children or assembly-line workers.
I realized through small hints and queues over time that the goal was to take over the maintenance of the project and make sure that we could fix things if something broke, but not add any new features.
They even had a management term for what we were doing. They called it KIR - Keep It Running! LOL
I prefer it to permanent, because besides the monetary aspect you can also get into new projects just starting out more often, and that is were you learn more when compared to maintenaince projects.
What type of opportunities would you recommend other than consulting?
https://www.irs.gov/forms-pubs/about-schedule-c-form-1040
A contractor is effectively a non-permanent employee: someone you hire for a fixed period because you have irregular work load and you need some extra people temporarily. I say effectively a non-permanent employee, but it's really skirting the edge here: if the relationship is too much like an employee, then the contractor is an employee for tax purposes.
A consultant is someone you hire for their expertise. They're a specialist; they tell you what you should be doing, rather than doing work you specify.
https://www.itworld.com/article/2801854/know-the-difference-...
https://www.crunch.co.uk/knowledge/tax/consultant-contractor...
IT contractors are also usually employed by contracting companies that take care of accounting and other overheads, and if they do things like marketing and referral, they'll eat a significant chunk of the fees too. I don't think there's a significant difference in organizational structure between contractors and consultants in this way. It's mostly that consultants address the problem at a bigger distance, and are more likely to be drawing up the plan, rather than working on the execution.
* How do you design software so that it is easier to modify over time?
* What will your software need that isn't specific to the business features requested when it is being operated in production?
You severely limit your experience when you keep yourself from being around for the aftermath of your software 3-5 years later.
i mean as an employee, if i get put in a hard position, sometimes the only choice is to quit, so, in that case, the CV would have an entry that you would not look back at to happily, but other than getting out as fast as you could why would being stuck in such a situation harm your career?
This was a bad look, because hiring managers want active developers for coding positions. I ended up not even mentioning that the position did not involve much coding on later interviews, I left after 6 months.
You are put in a tough position because you will have an entry of 3 to 6 months on your profile, which is generally a red flag for hiring managers as it's too short.
An entry with a full year or more will not raise any eyebrows, but 3 months will. Also, because you leave against their will, they won't give you references to the next jobs.
I did end up leaving it was a real nightware, and never looked back, but to this day I feel that I was flat out lied to on the interview about the job content.
In other interviews at other places, I was left out critical details, like for example that the team is moving to another city in two months, and you are expected to go with them.
So this why I say, you never know what you are getting into with software consulting, it's a shady business.
With the high turnover rates and the difficulty to find developers, hiring managers are incentivized to embellish otherwise mundane positions in the interview process, leading to unmotivated staff and further turnover.
You can describe the stint in several ways, such as "the strategic direction the consultancy took was away from software and into project management early in the project cycle. My personal strengths lie in..." or some such.
As an employee, probably. As a contractor, I prefer short contracts (1-3 months is short, 6 months is average) with a clear deliverable. If I wanted to just "sit around and do whatever" I'd get employed.
I can't even fathom how bad it must have been if using JIRA was preferable...
I spent six months building a single-page app (back when that was still an exciting sounding thing) for a major US financial institution; by the time we actually delivered it, the result was so watered down from the initial proposal that I could've just taken some screenshots from what my designer had produced six months earlier and put them in a PowerPoint deck and said "Done!" - because this was, in fact, what the VP at the company ended up doing, except they were screenshots from the web app we built that no one other than the VP himself ever used.
On the plus side, I became good friends with the VP and the project paid off a significant chunk of the mortgage on my first house.
(No judgement on you OP this is the situation we're in)
I stand by my original assessment that, from the perspective of both the client (everyone was happy with the end result) and my consultancy (we delivered work and we got paid), it was a success.
Aside, I assume you mean "to sustain the [USA] economy"? Perhaps you mean World economy, or EU, or ...?
Is there no other way to support human life than these accelerating grinding gears of money-shuffling?
Turned out that when the startup had brought him in as CTO they failed to mention that he was eventually going to be the sole developer.
I'm feeling it, because I was recently catfished.
Still, I can't imagine the culture falling that far in two years. Their was tons of meaty dev work being done. And day 1? Maybe they were just trying to ease him into the team? This might have been an effective Mr. Miyagi type move to help him get a greater understanding of how all the pieces work together.
This story smells bad, I would be interested to hear more details.
But they were plugging holes as fast as they could with contract recruiters that were throwing whatever would stick. I didn't even get to meet my team before I had an offer in hand.
From mine and his experience, whatever department that was (an ecommerce frontend), seems chaotic, with massive turnover.
Still accepting advice on how to negotiate a 100% raise.
Imagine a Controll Software - not written in StateDiagrams, but in either a sort of assembler, a drag&drop connection language or similar. Imagine parallel execution without correct communication handling (usually no semaphores etc.). Imagine massive mountains of copy pasted code (although not fail of the plattform, it encourages creating classes- called fb). Imagine some in-over-his-depths guy in panic adding and adding to this mountain of garbage, until the project gets critical and you are called.
Then you get to rewrite the mess ("Its almost done") while a men-choir of suits stands behind you, breathing in your neck till the fungi grow ("You are aware this factory has x-parts in storage and will stand still if you dont provide fix in time of x per hours").
In theory this is all super easy, its just, the coding culture is still in the late 80s. Thus its hell.
The bright side: clients usually come to me with just an idea, plan or sketches, almost all of my projects were built from the ground up, I totally technically owned them. This is a delight for any coder (and I code a lot, not just manage the team).
The dark side: many startups and green business ventures fail, and the failure rate is around 80%, even larger in the longer run. And I do the apps from the ground up, nurture them.. but sometimes I feel myself a gravedigger.. out of any 10 projects maybe 2 or three are still there after a couple of years.
If it’s solid but just a bit old or needs more features, you’re fine. But, if it’s crap, look out.
The quality or lack of is never down to the the people who built it (unless it was by the MD’s nephew or something), especially if the client blames them for it.
It just shows they can’t run a project properly and whatever you end up with will be just a slightly newer pile of crap. And they’ll slag you off to the next lot.
Number two red flag is if they say at any point “You tell us, you’re the experts!” This can be translated to, “We don’t know what we want but we’re going to reject whatever you say anyway.”
I disagree with this being a red flag. That's exactly why I hired someone to build me a small website. It's not because I don't know HTML / CSS / JS; it's because I'm bad at (visual) design. I wanted someone who knows what they're doing to use their expertise and give me a good product.
The problems start when the client either can’t or won’t explain what they want, then gets upset that what you produce doesn’t match what’s in their heads. At that point they start trying to undo every decision and things go south rapidly.
One company I worked for had a great website. One of my coworkers worked on it as his baby and took great care of it. Rest of the software stack was a dumpster fire.
One other coworker came on board because they thought "no bad company would ever have a bad website". The guy who hired him left a week after he joined. One developer left every week for four weeks afterwards.
Website quality is a weak signal; I'd say if a website didn't have any errors or warnings in $BROWSER DevTools, or made a mention of not pasting JavaScript here or having an explicit "oh hey you're a developer we're hiring", then that's good. Otherwise keep asking questions.
Edit : The article doesn't mention anything about user journeys. Hence the thought :-)
Just yesterday, a junior developer from my team came to me about a request to generate some output from historical data. I went back to the business side and determined it was just a simple switch of several columns in the input data to get the results.
My junior developer at first thought it was some monumental problem that was going to require a lot of work.
"We don't have time to think, just do!" is a recipe for disaster.
I'm a noob when it comes to coding but I worked a technical job with customers for 20 years before changing paths.
I was in a position where I joined a place as the "new old guy" and several new college grads.
One day the president of the company comes to me and asks "You know the questions to ask! Some of our experienced guys don't."
It takes a lot of effort for two people or groups to form an idea and be on the same page, understanding "all" doesn't mean *, thinking of roadblocks before you get there (seeing them coming), softly working around those roadblocks, helping frustrated people, offering alternatives without going off the rails, listening closely to find out what is REALLY important and etc. I think that stuff just comes with experience working with humans.
My own experience makes me think everyone should be required to work some form of technical support for a while ;)