Me, I'm paid to translate someone's idea from one language to another. The value to the business is already understood by the one conveying the original idea. My only job is to ensure that the entity on the other side fully understands what was originally communicated without hinderance through language barriers.
My working theory about this is that the industry is driven by resume-driven development. Recruiters filter resumes with a keyword based search : 'Do you have React experience ?', 'What about docker ?', 'Do you do Ruby on Rails ?'. If you cannot show experience in the current hotness, your chances in the job market diminishes. So people pick up the new hotness and implement their next solution with that technology whether or not it is the right tool for the job. If we fix the job market, this problem might automatically disappear.
Another solution could be encouraging personal projects. Many companies over-work their employees to the point that they cannot do anything in their spare time. Give employees free time and encourage them to play with new technology in their personal projects. The curious ones will have an outlet to channel their energies and you will get a rock solid stack. Also, they will be knowledgeable to take you forward when a problem that requires their newfound knowledge arises in your organization.
The overwork thing has to be culture. I'm sure they think they're cost minimizing, but I doubt adding the additional labor costs more than the additional time of the current staff doing it all alone and being stressed out and so on. The "stressed out and so on" adds up to negatives that your company will pay out.
Remember that managers too respond to incentives. People working 9-5 are probably more productive than those doing 12 hour days, but which is more likely to keep the VC money flowing?
It definitely factors into employee turnover rates. That is probably also where employees hurt themselves. People don't like looking for work and for good reason.
> Another solution could be encouraging personal projects.
Agree. This is necessary to encourage learning, which helps keep people sharp, which in turn benefits the projects that they are working on in the day job. Even if the technology is the "same old".
A couple of decades ago, many software developers were content using the tools they had and knew. Few demonstrated the eagerness and openness to try something new. These few were also the ones who were better at coming up with out of the box solutions because they were willing to try something new -- both tools and/or approaches. Now, we have reached a point where the bare minimum required of a software developer is familiarity and comfort with the new and shiny, leading to the reverse problem we had early on. Now, people can spend way too much time and energy learning and trying out new tech that they miss out on the opportunity of staying long enough with a technology to learn from experience.
In other words, today we spend way too much time on accidental complexity than on essential complexity.
The root cause of writing unnecessary code is the way the work day and compensatory systems of the modern workplace are structured. Employed software and infrastructure engineers are not paid to just drop in the simplest, most appropriate solution, do the minor customizations/reconfigurations that may be needed, and get out. They're paid to be in butt-in-chair for at least 8 hours per day, and the presumption is that they're engineering that whole time. In reality, places often must make up tasks to keep their employees busy, and using the most efficient solution is disincentivized, because you have to say you're doing something for those 8 hours.
I think the fact that we have the white-collar workforce organized after the assembly line pattern is the primary cause of unnecessary, borderline intentional complication, which includes mixing in unstable/untested components. If we could find a way to compensate engineers fairly without monopolizing their time, we'd be much better off, because the need to continually invent additional work for oneself would go away.
The bliss of a stable, low-maintenance project can be had through side projects, which often work fine for years with minimal modifications. It's really rewarding to go back to the same utility that you've written and know that the comparatively little quantity of time you spent on it is still paying dividends years later. There's an awesome sense of pride attached to that.
In reality, places often must make up tasks to keep their employees busy, and using the most efficient solution is disincentivized, because you have to say you're doing something for those 8 hours.
This does not match my experience. Slow times are for experimenting with things and catching up on less-urgent tasks.
You've led a charmed life. In my 25 years in this business, I've found that very little induces the same level of panic in management as "experimenting" with something, especially something that you can't put a solid "business case" behind and "estimate" down to the nearest half hour.
Which is only to be expected. Middle management is not about leadership but all about mitigating risk (Seth Godin explains this quite well in 'Tribes').
It's both a shame and moronic that often assembly line paradigms of management are applied to non-assembly line work (i.e. work that isn't the same for each iteration).
What's needed is to reframe work in terms of value instead of time wasted.
What's interesting is that if you look at history, there are different 'assembly line' paradigms of management, one which could be maybe be termed 'classic American' style (which could be argued necessitated the rise of old-school unions, leading to anti-productive standoffs between management and labor), and the 'Toyota style' which ironically was founded/seeded in Japan by Americans which could not get larger American car companies to listen at the time.
The 'Toyota style' could be argued as more responsive to worker initiative and fits better philosophically with software work. (And Agile is influenced by Toyota-way thinking too, though in a mutated form..)
The "Toyota style" has already played a substantial role in the philosophy of influential technology companies like Apple and Pixar. Steve Jobs was a known admirer of W. Edwards Deming, who created it.
Yes, that. I always feel managers are pressured to make sure devs are worked 8 hours a day, necessarily or not. As for side projects, it is really hard to keep a flow doing that knowing that at any time you may be given a "real task" or a maintenance issue to work on. Maybe contractors have a different work day since they are paid by the hour to do specific things, but full time always have the issue of nothing to do but not being allowed to go home or work on something to enhance knowledge.
I saw this at one large uk Telco Some one was going for a promotion so they spent a year and a team of 15 people to redevelop an existing perl system into an oracle based one as oracle was the company standard.
one of the markers for promotion was manage a team of x size and a > 1million budget - so they where gaming the system not the best use of the share holders money
Almost half of my time in the past few months have gone into interviewing and hiring and I approached the subject with a complete beginners mindset and tinkered to see what works. Much to my chagrin turns out there is a positive selection effect to filter candidates by resumes based on hot tech. Maybe the smart ones know this increases there employability? Maybe they are naturally more curious? Who knows, it just seem to be a good signal.
I'm not sure what you consider hot tech but I can assure you whatever it is it is based on tech that has been around for ages and has just been rebranded. I find that people that hop from "hot tech" to "hot tech" don't ever build up a depth of knowledge and understanding to tackle hard problems in an elegant way. It is essentially a major contributor to the 1 year of experience repeated 10 times phenomena.
>I find that people that hop from "hot tech" to "hot tech" don't ever build up a depth of knowledge and understanding to tackle hard problems in an elegant way
You immediately assumed that the folks I found are just jumping from tech to tech without building anything substantial. Which is probably also bias, just an opposite of mine. You also assumed that I didn't vet them or test them on "elegant solutions". Maybe your heuristic worked for you. But this heuristic, in my current situation is thus far working for me.
Tackling hard problem is often so much social endeavor than the effort to solve it. You have to convince everyone the solution works despite all the bias they might have.
Maybe that's why many of the major changes you see in tech, like Linux, Git, Vim or Redis started as a single person's work rather than a clever corporate product.
> Recruiters filter resumes with a keyword based search
Although true, this is is somewhat shooting the messenger. If as a client of the recruiter I ask for COBOL developers and all I get are Clojure resumes because the recruiter thinks it's cooler, then the recruiter won't be my recruiter for very long.
Surely where there's an issue it's that the recruiters are being asked for developers with those attributes. They're presumably being asked because the employer, for good or ill is seeking developers with those attributes.
Now, I've personally seen 4 reasons for hiring devs with cutting edge knowledge: because it's cool, because it's the only way to attract good talent, because we checked and we absolutely need that technology and because we run a research lab looking into cutting edge tech we may or may not use.
The latter two are very good reasons to seek hotness. They're also the least likely to be the reason, in my experience. Using shiny, shiny to attract talent is often a successful approach. And who doesn't like cool stuff (though it's a terrible justification)?
It has been suggested several times on HN that another reason is that it attracts younger coders.
Younger coders tend to be more willing to just follow the lead of the management, rather than ask "is this really going to solve the problem?"
Younger coders will put in massively more hours -- this may result in problems like reinventing the wheel, piles of garbage code, etc. -- but it generally "feels good" to be the manager with an energetic, 24-hour around the clock team of young coders.
Younger coders can be paid less, and are willing to forego benefits, stability, medical plans, or even pay sometimes.
I can't emphasise how true this is. I've written tonnes of temporary scripts that parse some files or rename some directories, and then later discovered that I could have done it with a single UNIX command.
I'm not employed as a professional software developer, so I still don't actually use the helpful UNIX commands. Takes all the fun out of it. :P
The other day I had problems with grep, so I rewrote it in JavaScript ... I could have used awk, but at least my script is more then double as fast as awk. I think it's some sort of procrastination and being self managed. Reminds me that I should get off HN and start working.
I was investigating an e-mail problem, searching log files across several e-mail servers ... Did it go through this server, or that server ? After a lot of frustration I found out grep didn't show all matches ... I does report the right amount with the -c argument though.
This is a great post. I think the "paid to write code" is often a byproduct of environment - whether it's poor engineering leadership, bad productivity measurement, etc.
I'm paid to keep software systems up and resolve issues. Sometimes this means adding, removing, or modifying code. A lot of the time, it just means clicking the right buttons at the right time. Really, I'm paid to know which of those actions is appropriate in various circumstances, and to get it done when it needs to be.
Not sure what the articles point is? That you shouldn't write an application if you can use an off the shelf tool? Who does that?
I'm paid to write code because someone wanted an application. I don't think I could tell the customers who buy our application that they should learn some bash or excel and solve their business problems?
I assume under some rare circumstances a developer isn't faced with writing an app (site, CAD program, OS, ...) but instead to solve some business problem internal to a business - then you have the option of not writing code.
Your job is to solve business problems. You happen to use code as the tool to do so because it lends itself to building better, more reliable, more scalable solutions.
Nobody pays for a lump of code, they pay for a tool that solves a problem they have.
Depends really. A surprisingly large number of organisations don't seem to be equipped to handle business input from the development staff or any kind of "productivity multiplier" contributions. E.g: making the team more efficient, reducing signup friction, fixing UX annoyances, inventing a new feature or product, improving security practices, reducing defect rates by introducing CI/static analysis/whatever.
In this case the job of the developer will be to write code and it doesn't make sense to pay high salaries because the ROI is not there.
This leads to the situation where very good developers aren't paid good salaries because in such a company they are literally not worth the money.
The customer pays my employer for a solution and my employer pays me to create it but I get your point. I just didn't agree with the argument of the article in general - most of devs can't use a piece of shell script to solve a problem they would otherwise code. Simply because we work within the boundaries of a single product such as a large desktop application.
I don't solve my employers business problems, I solve the customers business problems an the only way to do it is to code it in the application.
> Nobody pays for a lump of code, they pay for a tool that solves a problem they have.
A more cynical situation, which I have seen all too often, is that they pay for the line items on the RFP. Whether or not those features will ever be used or are in any way beneficial.
- NIH. If you think it's programmers who primarily suffer from NIH syndrome, check again. Just how many times you end up writing something that's already done because your bosses insist they must have an in-house solution?
- Nonsolving a nonproblem. A lot of code we write is meant to solve a problem that doesn't really exist, is created by stupid decisions higher up the chain, or sometimes just shouldn't be solved in the first place (e.g. tools facilitating an unethical business model).
So yeah, I'm often paid to write code - because the decision that code must be written is made by people above me.
Sometimes, as a developer, I ask higher level questions about the business. Who is the customer? What problems do they have that we are trying to solve? How does this business make money? How are the executives measured?
These are questions that are relevant if you want me to add value in a non code monkey way. But, sometimes, when I ask these questions, I get looks that say "You're paid to write code, so stop asking non code questions." Or maybe I'm just projecting.
> Nobody pays for a lump of code, they pay for a tool that solves a problem they have.
Of course they're paying for code. They're paying for code that does something useful, and which may or may not produce value for their business. You can't separate the two.
I think his point is that engineers tend to favor complicated solutions, and that they shouldn't do that. Every line of code you write or modify is potential technical debt that you'll have to own. The author appears to indicate that this is bad, and also appears to recommend making wider use of pre-existing solutions to prevent it. That's fine as far as it goes, but it's a simplification.
The piece does feel incomplete in that it doesn't discuss the incentives behind the decision to "write code" or not.
The simple fact that we always seem to come back to is that once you learn the basics, good engineering just comes down to good judgment, which is only gained through years of dedicated trial and error. Is it better to write some glue code to bounce data between 8 different extant programs and make final transformations or to write your own program that handles the process soup-to-nuts? The answer is now and will always be "it depends" (and quite frequently, it involves elements of both). We need to make sure that the social incentive structures align with the engineering goals (i.e., don't tell someone that if they make something stable and low-maintenance, they'll unemploy themselves) and then we can trust people to do good, iterative work.
Every line of code you write or modify is potential technical debt that someone will have to own.
With the turnover rate in this industry, I'm not sure anyone plans to be around when the monstrosity that they wrote starts to become a maintenance nightmare.
Yes, sorry if I was unclear: that was my point. When I as a developer is paid to do something, usually someone (my manager, the customer etc) has already decided that whatever problem there is can't be solved without making a program specifically for it.
If the business requirement is to produce something to sell to other companies, more likely than not you will end up writing software. You simply cannot build enough entry barriers and protectable IP by glueing together a bunch of standard components in a clever way.
Every single human being is "slave" to others. We call that "specialization". The only exception - and not even completely so - are people like the old 18th/19th century trappers who lived alone in the West. But even they relied on civilization for traps, weapons and a lot of other things and had to deliver something (furs), so they too were just "slaves"? Even people living in hunter-gatherer societies are "slave" to one another. Try being useless to your tribe in such a society because "you feel like it".
I was in the UK a few months ago for a meeting and they had a plate of sorts in the room with a list of company guidelines. One of them was ‘Everybody sells’.
It seems obvious but I'd never seen it put so starkly.
My beep-boop sysadmin job is at least 50% internal public relations, in one form or another. Pretty much any job interacting with humans is, I think, which is basically all of them.
You know these occasioanl threads about engineer burnouts we see and post on HN? Well, I actually feel that when you are "burned out" and don't feel like writing complex systems is "fun" anymore, you actually become a better engineer - exactly for the reason described in this post.
Its more likely to be going downhill because everyone is jumping on the latest hipster bandwagon. NoSQL is a perfect example where many people / projects would be far better off learning about how to use a relation database efficiently rather than adding a new trendy tech to their CV while having limited experience in that new database (most of the projects I hear about are storing their data on a single server).
I'm not really sure what they are paying me for anymore.
I do analysis, planning, testing, development, client presentations and when I raise this concern with my TL I always get the 'cross-functional team' argument.
> And people wonder why software quality is going downhill.
Quite the opposite! Most of the poor quality is due to excessive complexity, little care for reliability, use of too many libraries and frameworks of questionable quality.
All of this comes from the idea that a developer is paid to write code.
A lot of strong engineers that I met in Amazon and elsewhere would use the minimum amount of code and libraries required and spend as much time reducing complexity and deleting other people code as writing new code.
If you see yourself as a software developer instead of problem solver, you tend to solve all your problems by writing code. In many cases problems can be solved by adjusting processes, improving culture, education or just by learning to use the current tools in more efficient ways.
"Developer" rather than mere "coder" should mean you're aware of the full import of the system from requirement to end user deployment and production. Sometimes it does.
Enter the insane notion of separating developers from end users. You have sales and managers talking to customers, then writing you a half-assed specification that's broken and illogical because they're not trained in noticing general ideas behind specific points. sigh.
True, but it's good to at least have someone deeply technical on the discussion too, just for the ability to come up with generalizations and - after presenting them to the customer - to confirm whether they're sound, or whether the customer has a completely different model in their head.
It's easier to do that with the customer than with the spec - specifications can't talk back to you.
Heh. It's much easier to write a kludge and patch it 500 times than perform a culture change at my place. I'll get rewarded for "fixing" the application and be seen as valuable in the former, and quite easily despised in the latter.
> Gall’s Fundamental Theorem of Systems is that new systems mean new problems. I think the same can safely be said of code—more code, more problems. Do it without a new system if you can.
I agree with the basic idea here, yes. But I would have to disagree strongly with the last part.
The problem with Do it without a new system if you can is that we need judgment to decide when to make a new system and when not. Sometimes just writing a small piece from scratch instead of using (and repurposing!) a poorly-matched prior system is a hell of a lot simpler.
"You may not be paid to write code, but when being hired we're going to throw every convoluted or esoteric brain scratching coding test at you for you to pass, which you'll then never have to do again. Until you apply for your next job, that is."
The major problem of bringing in external technologies is that they take over your architecture, not that they might introduce bugs.
There is no catch-all architecture, so there is guaranteed to be some impedance mismatch between the expectations of your project, and the provisions of the 3rd party tool. Heaven help you if you need the facilities of multiple architectures, and try to marshal and connect disparate datatypes and calling/threading assumptions together.
As programmers, we work with general purpose programming languages. Many project-specific problems are not difficult to solve in a custom manner, given somebody with enough experience and hindsight to know how to write such a forward-looking thing robustly. It is a serious consideration whether or not to defer your architecture to generic external sources that were not written with your unique needs in mind. And even if you do, it is by far a best practice to ensure that such things live behind an application-specific abstraction separating out your project-specific code from entangling 3rd party code, allowing you to perform the inevitable migration to a different platform later.
This is an issue we're grappling with at present, as we move all our sites out to AWS: do we build our apps to use the incredibly tempting AWS services, or do it ourselves?
Our present approach is "hell yeah, if it can be outsourced it should be" and that applies to services too. We do keep an awareness of what it would take to do each thing by hand again though.
With AWS, I think cost becomes a significant issue in selecting which services to use, more so than development issues.
But then again I've also always found that once you start coding to it, AWS gets you 90% of what you want, and you spend the other 90% of the time fleshing out the exact retry, migration, and error-handling behaviors you need manually on top of it. :-P
Meta question: do software developers typically enjoy these types of officious, bossy article that state what is and what must / must not be done?
The tone of these types of posts always make me chuckle. And, I see similar types of articles on here often. When I read these, I feel like Dad is mad at me for being a bad programmer.
I take it as an opinion. He's trying to sell that opinion. What he's leaving out is:
1. Leaky abstractions
2. Software bloat (using a massive framework to solve a simple problem)
3. Oops, I picked a lemon, now lets roll back all that glue code.
4. Code dependencies.
5. Upgrade hell.
It's a fad, it too shall pass, assuming programmers still remember how to program non-trivial things after the fad.
Nowadays it pays well to be a programmer (oh wait, developer; engineer; whatever title helps you rationalize), programming-qua-profession has exploded (it even draws the feminists... why aren't they into carpentary? draws governments, America Codes!), and articles are written with the assumption that everyone wants to be a good cog (oh, employee) and consider business needs above all, play good by the team, understand why company interests are always more important. If you don't do (think) this or that, well, you're just not being a professional! Why would BigImportantEntity, or anyone for that matter, hire you?
It's much easier for many people to come up with these articles than it is to write something technical.
I write code since forever, addicted to it. I happen to be in a field that pays good money for my addiction. So far, despite the stupidity of the profession, things turn out mostly OK. Why does someone pay me? Don't care. As long as the relationship is beneficial to me, it's OK. I feel I have more in common with starving artists in other fields, than some corporate official looking out for business interests. So I'd be a starving programmer in a parallel world where programming is not a hot profession. Now, if I had my own business, then I brought all these nontechnical issues upon myself. But then, I'll pay myself for whatever reason I want.
I am a programming addict since early teenage years. I like writing code. But I also like that code to do something fun or useful.
One time, it came the day I was supposed to enter the job market. So I looked at what companies - around me and worldwide - are doing, I read the stuff about "solving business problems" instead of "just writing code"... and I realized that if I were to really care about this, I would be unemployable. Because most of the "business needs" in our industry are trivial bullshit stuff that's at best neutral (more often harmful) to society, and only exists to make money for some entrepreneur. I don't give a shit, and will never give a shit about those problems. So - through many years of depression and burnout - I learned to ignore most of the business goals and focus on doing my part the best I can.
For example, right now I'm paid for developing an application that shouldn't really exist in the first place, and makes little sense to anyone - not to developers, not to people who will end up uing it - except the management. But well, management decides. So if I'm making this application anyway, I'm focusing on making it as useful as possible. Management asks for features. I do the ones that make sense and politely suggest changes in the ones that are idiotic. They're happy. I'm paid. When they're not looking, I'm venting out on HackerNews.
--
So yeah, to people constantly writing about focusing on delivering business values: please tell me how to look for values worth delivering, in the sea of moral bankrupcy the current job market is.
Right on. Can we cut the bullshit about how a wage worker is supposed to care about the customer, the business, or any of that? Does the person working in the drive through at McDonalds care about the customer? Of course not.
Now, if I was a partner in a business with some equity stake, then I would mop the floors if that's what I felt would increase the value of my stake. But as a wage worker, when you tell me to mop the floor, I tell you "that's not my fucking job".
People act in their own self interest. Why is this so god damn difficult to understand? Fuck!
It's pretty amusing when you have to keep repeating to a client that the off-the-shelf tool is better, cheaper, and is immediately available to them. Yet they still argue for the development of a new system. So I don't think this push towards custom builds only comes from the developers side of things.
And another thing worth pointing out is: most employers hire you to write code. That's the job spec. So don't be surprised that that's what we end up doing.
Wake me up the next time a 5-line shell script in Bash that uses only standard tools and runs off of any default Debian sells with a license cost of $20 (only) -- you know, for the 5 lines, not anything else -- and anyone pays it.
Doesn't matter what it does. It is literally impossible to sell even $20 worth of the solution the person advocates. Go ahead: link me to anywhere in the web selling a 5-line bash file without anything else. I'm waiting.
You can do a lot in 5 lines, too. lalalala. waiting. While I wait I think I'll make some money coding something people actually pay for. /s
Seriously though, while the author's point might stand in many sys admin and even systems integration roles - most of the software world actually pays for deliverables: the clearest example of which is consumers doing so. People would rather spend 20 hours cursing, and then give up, rather than pay for a systems integration script that generalizes and solves their problem. It's what the market demands. This article really would make sense if it came from the person paying -- but it doesn't. nobody who is paying actually says the words the article chose for the title. Yes, you are paid to code.
I'm not 100% sure why you're asking for a link to a product when I think it's fairly clear that he's talking about business solutions. Or to give a weak example: "we have system X and system Y and need them to talk."
After you write something like that you don't turn around and sell it on the web.
> Wake me up the next time a 5-line shell script in Bash
Or when somebody can write a 5-line shell script in Bash that:
a) typical non-programmers can and will use
b) produces enough diagnostic information that anybody (programmer or not) can use to troubleshoot when something inevitably goes wrong - whether it's user input, network connectivity, a missing dependency...
I get what he's saying, but he's talking about a pretty small subset of what we really do.
Every now and then we'll see an HN thread that asks something like: what do you know now that you wish you would have known when you started programming?
This. This is the thing that took the longest to sink in and had the biggest impact. There were a lot of cool languages, tools, platforms, and systems along the way, and I was stoked picking up each one and coding -- but after decades of that, I realized I was focusing on the wrong thing.
I think the thing that convinced me was when I got to start watching lots of technology teams in the wild across multiple organizations. So many times I would see conversations and tons of problem-solving effort being spent on the tools to solve the problem instead of the problem itself.
A couple of years ago I was teaching tech practices to a team that was deploying on iOS, Droid, and the web. After we went over TDD, ATDD, and the CI/CD pipeline, I emphasized how crucial it was not to silo. When I finished, a young developer took me aside.
"You don't understand. We have coders here who just want to do Java. They want to be the best Java programmers they possibly can be."
I told him that he didn't understand. Nobody gave a rat's ass about people wanting to program Java. They cared about whether the team had both the people and technical skills to solve a problem they have. It would be as if a carpenter refused to work on a cabinet because it wouldn't involve using his favorite hammer. You're focusing on the wrong thing.
Sadly, once you get this, the industry is all too happy to punish you for it. That's because the resume/interview/recruitment world is interested in buzzwords and coolkids tech, not actually whether or not you can make things people want. This means sadly, in a way, if you continue growing, it's entirely possible to "grow out of" programming.
> I think the thing that convinced me was when I got to start watching lots of technology teams in the wild across multiple organizations. So many times I would see conversations and tons of problem-solving effort being spent on the tools to solve the problem instead of the problem itself
Your insight really hit home. Especially since I've been on a new software dev position for about a month now. This is the overwhelming issue that is already reared its ugly head, is massively frustrating and I feel (nearly) powerless to stop it.
This is a good article, and the quote in the middle is absolutely amazing -- it belongs up there with some of the most insightful quotes about software ever (and it was not even directly about software).
I sum the quote up as, "Systems are sentient beings like the One True Ring, and they will absorb you. Soon, though you believe you are thinking freely, you will actually be merely a part of the System, thinking what it wants you to think." So true!
But ... Taco Bell programming still creates a new system. That's a flaw in the article's premise.
If you solve a problem by stringing together 11 tools, then yes, you should get some benefits from reusing preexisting tools. But now, you have a system with some rube goldberg characteristics, plus you've written a bunch of "glue code" (which is "new code") in the process.
Those systems can often turn out to be more complex.
I sorta get the idea of the article. Working smart etc. However the incentives in organizations run often counter to that. Gluing together existing pieces to do some grunt work is rarely good for your career. Building new glorious systems is much more likely to do that.
Also for orgs that do the developing for other orgs it isn't really optimal to offer the quick and efficient solutions unless competitors are doing the same.
I think I have the opposite issue at my current job as the person in charge wants to put every site, every db, every cron job ,every filesystem on one server and then wonder why we have a io problem...
1 instance on aws...sure hope our availability zone stays up next year.
To be fair, running everything on the same host is very efficient. It's just risky in terms of (lack of) redundancy and unpredictable loads.
When hardware was expensive the idea was to make everything as tiny and efficient as possible. Now that hardware is cheap the idea is to make everything as scalable as possible so as to take advantage of all that extra hardware you can now afford.
The next phase of this evolution is to go back to making everything tiny and efficient again as we reach the theoretical limits of horizontal scalability. A good way to "force" such practices is to make your developers use single (or just limited) hardware for everything.
I doubt your boss is coming from this angle but I've actually witnessed this put into practice by forcing a small development team to run their code on Raspberry Pis. It really brings home the idea that, "No, really: Your code is slow and inefficient."
It makes people re-think their architectures and often forces them to divide tasks up into smaller pieces that can be written efficiently. Also, nothing says, "ditch your ridiculously complicated and slow build process" than forcing it to run on embedded hardware.
If your build forces a multi-core embedded system with a gig of RAM to thrash and crash you need to re-think things a bit =)
Of course they did! Especially in the web world. It's just that this million other solutions are all crap you can't reuse even if you wanted to, so you too have to do the same CRUD thing everyone else is doing, only in a slightly different way.
171 comments
[ 2.6 ms ] story [ 242 ms ] threadExcept they might have input in the processes.
Another solution could be encouraging personal projects. Many companies over-work their employees to the point that they cannot do anything in their spare time. Give employees free time and encourage them to play with new technology in their personal projects. The curious ones will have an outlet to channel their energies and you will get a rock solid stack. Also, they will be knowledgeable to take you forward when a problem that requires their newfound knowledge arises in your organization.
Agree. This is necessary to encourage learning, which helps keep people sharp, which in turn benefits the projects that they are working on in the day job. Even if the technology is the "same old".
A couple of decades ago, many software developers were content using the tools they had and knew. Few demonstrated the eagerness and openness to try something new. These few were also the ones who were better at coming up with out of the box solutions because they were willing to try something new -- both tools and/or approaches. Now, we have reached a point where the bare minimum required of a software developer is familiarity and comfort with the new and shiny, leading to the reverse problem we had early on. Now, people can spend way too much time and energy learning and trying out new tech that they miss out on the opportunity of staying long enough with a technology to learn from experience.
In other words, today we spend way too much time on accidental complexity than on essential complexity.
This. So much this!
Hell, I'd settle for just not discouraging it so damned hard.
I think the fact that we have the white-collar workforce organized after the assembly line pattern is the primary cause of unnecessary, borderline intentional complication, which includes mixing in unstable/untested components. If we could find a way to compensate engineers fairly without monopolizing their time, we'd be much better off, because the need to continually invent additional work for oneself would go away.
The bliss of a stable, low-maintenance project can be had through side projects, which often work fine for years with minimal modifications. It's really rewarding to go back to the same utility that you've written and know that the comparatively little quantity of time you spent on it is still paying dividends years later. There's an awesome sense of pride attached to that.
This does not match my experience. Slow times are for experimenting with things and catching up on less-urgent tasks.
You've led a charmed life. In my 25 years in this business, I've found that very little induces the same level of panic in management as "experimenting" with something, especially something that you can't put a solid "business case" behind and "estimate" down to the nearest half hour.
It's both a shame and moronic that often assembly line paradigms of management are applied to non-assembly line work (i.e. work that isn't the same for each iteration).
What's needed is to reframe work in terms of value instead of time wasted.
The 'Toyota style' could be argued as more responsive to worker initiative and fits better philosophically with software work. (And Agile is influenced by Toyota-way thinking too, though in a mutated form..)
one of the markers for promotion was manage a team of x size and a > 1million budget - so they where gaming the system not the best use of the share holders money
your bias is showing.
I'm not sure what you consider hot tech but I can assure you whatever it is it is based on tech that has been around for ages and has just been rebranded. I find that people that hop from "hot tech" to "hot tech" don't ever build up a depth of knowledge and understanding to tackle hard problems in an elegant way. It is essentially a major contributor to the 1 year of experience repeated 10 times phenomena.
You immediately assumed that the folks I found are just jumping from tech to tech without building anything substantial. Which is probably also bias, just an opposite of mine. You also assumed that I didn't vet them or test them on "elegant solutions". Maybe your heuristic worked for you. But this heuristic, in my current situation is thus far working for me.
Maybe that's why many of the major changes you see in tech, like Linux, Git, Vim or Redis started as a single person's work rather than a clever corporate product.
Although true, this is is somewhat shooting the messenger. If as a client of the recruiter I ask for COBOL developers and all I get are Clojure resumes because the recruiter thinks it's cooler, then the recruiter won't be my recruiter for very long.
Surely where there's an issue it's that the recruiters are being asked for developers with those attributes. They're presumably being asked because the employer, for good or ill is seeking developers with those attributes.
Now, I've personally seen 4 reasons for hiring devs with cutting edge knowledge: because it's cool, because it's the only way to attract good talent, because we checked and we absolutely need that technology and because we run a research lab looking into cutting edge tech we may or may not use.
The latter two are very good reasons to seek hotness. They're also the least likely to be the reason, in my experience. Using shiny, shiny to attract talent is often a successful approach. And who doesn't like cool stuff (though it's a terrible justification)?
Younger coders tend to be more willing to just follow the lead of the management, rather than ask "is this really going to solve the problem?"
Younger coders will put in massively more hours -- this may result in problems like reinventing the wheel, piles of garbage code, etc. -- but it generally "feels good" to be the manager with an energetic, 24-hour around the clock team of young coders.
Younger coders can be paid less, and are willing to forego benefits, stability, medical plans, or even pay sometimes.
If you don't work in that field, you're fine :D
I'm not employed as a professional software developer, so I still don't actually use the helpful UNIX commands. Takes all the fun out of it. :P
I find this very hard to believe. Are you sure your awk implementation was okay?
I'm paid to write code because someone wanted an application. I don't think I could tell the customers who buy our application that they should learn some bash or excel and solve their business problems?
I assume under some rare circumstances a developer isn't faced with writing an app (site, CAD program, OS, ...) but instead to solve some business problem internal to a business - then you have the option of not writing code.
Your job is to solve business problems. You happen to use code as the tool to do so because it lends itself to building better, more reliable, more scalable solutions.
Nobody pays for a lump of code, they pay for a tool that solves a problem they have.
In this case the job of the developer will be to write code and it doesn't make sense to pay high salaries because the ROI is not there.
This leads to the situation where very good developers aren't paid good salaries because in such a company they are literally not worth the money.
I don't solve my employers business problems, I solve the customers business problems an the only way to do it is to code it in the application.
A more cynical situation, which I have seen all too often, is that they pay for the line items on the RFP. Whether or not those features will ever be used or are in any way beneficial.
- NIH. If you think it's programmers who primarily suffer from NIH syndrome, check again. Just how many times you end up writing something that's already done because your bosses insist they must have an in-house solution?
- Nonsolving a nonproblem. A lot of code we write is meant to solve a problem that doesn't really exist, is created by stupid decisions higher up the chain, or sometimes just shouldn't be solved in the first place (e.g. tools facilitating an unethical business model).
So yeah, I'm often paid to write code - because the decision that code must be written is made by people above me.
These are questions that are relevant if you want me to add value in a non code monkey way. But, sometimes, when I ask these questions, I get looks that say "You're paid to write code, so stop asking non code questions." Or maybe I'm just projecting.
Of course they're paying for code. They're paying for code that does something useful, and which may or may not produce value for their business. You can't separate the two.
The piece does feel incomplete in that it doesn't discuss the incentives behind the decision to "write code" or not.
The simple fact that we always seem to come back to is that once you learn the basics, good engineering just comes down to good judgment, which is only gained through years of dedicated trial and error. Is it better to write some glue code to bounce data between 8 different extant programs and make final transformations or to write your own program that handles the process soup-to-nuts? The answer is now and will always be "it depends" (and quite frequently, it involves elements of both). We need to make sure that the social incentive structures align with the engineering goals (i.e., don't tell someone that if they make something stable and low-maintenance, they'll unemploy themselves) and then we can trust people to do good, iterative work.
With the turnover rate in this industry, I'm not sure anyone plans to be around when the monstrosity that they wrote starts to become a maintenance nightmare.
Lots of people? Everyone who ever bought, downloaded or otherwise acquired any software not written by themselves?
Related: https://medium.com/@kevin_ashton/what-coke-contains-221d4499...
It seems obvious but I'd never seen it put so starkly.
Of course a Software engineer is paid to write code - if they're not, you probably want a different person.
Maybe we need a new job title: "Business Value Expander"
Requirements: Glue together everything else that's already been written by other people, and make the business rich.
What could possibly go wrong.
I do analysis, planning, testing, development, client presentations and when I raise this concern with my TL I always get the 'cross-functional team' argument.
You just do everything you're asked to, in order that the business makes money - code ? Meh, anyone can do that.
How many other professions suffer the need to be 'cross-functional' ?
Quite the opposite! Most of the poor quality is due to excessive complexity, little care for reliability, use of too many libraries and frameworks of questionable quality. All of this comes from the idea that a developer is paid to write code.
A lot of strong engineers that I met in Amazon and elsewhere would use the minimum amount of code and libraries required and spend as much time reducing complexity and deleting other people code as writing new code.
The "full stack developers" have got it covered
It's easier to do that with the customer than with the spec - specifications can't talk back to you.
Computers do what you tell them to, most of the time.
> Gall’s Fundamental Theorem of Systems is that new systems mean new problems. I think the same can safely be said of code—more code, more problems. Do it without a new system if you can.
I agree with the basic idea here, yes. But I would have to disagree strongly with the last part.
The problem with Do it without a new system if you can is that we need judgment to decide when to make a new system and when not. Sometimes just writing a small piece from scratch instead of using (and repurposing!) a poorly-matched prior system is a hell of a lot simpler.
There is no catch-all architecture, so there is guaranteed to be some impedance mismatch between the expectations of your project, and the provisions of the 3rd party tool. Heaven help you if you need the facilities of multiple architectures, and try to marshal and connect disparate datatypes and calling/threading assumptions together.
As programmers, we work with general purpose programming languages. Many project-specific problems are not difficult to solve in a custom manner, given somebody with enough experience and hindsight to know how to write such a forward-looking thing robustly. It is a serious consideration whether or not to defer your architecture to generic external sources that were not written with your unique needs in mind. And even if you do, it is by far a best practice to ensure that such things live behind an application-specific abstraction separating out your project-specific code from entangling 3rd party code, allowing you to perform the inevitable migration to a different platform later.
Our present approach is "hell yeah, if it can be outsourced it should be" and that applies to services too. We do keep an awareness of what it would take to do each thing by hand again though.
But then again I've also always found that once you start coding to it, AWS gets you 90% of what you want, and you spend the other 90% of the time fleshing out the exact retry, migration, and error-handling behaviors you need manually on top of it. :-P
I think its great. My future support burden just decreased. That is a big piece of code that will result in zero bug reports.
The tone of these types of posts always make me chuckle. And, I see similar types of articles on here often. When I read these, I feel like Dad is mad at me for being a bad programmer.
1. Leaky abstractions 2. Software bloat (using a massive framework to solve a simple problem) 3. Oops, I picked a lemon, now lets roll back all that glue code. 4. Code dependencies. 5. Upgrade hell.
It's a fad, it too shall pass, assuming programmers still remember how to program non-trivial things after the fad.
It's much easier for many people to come up with these articles than it is to write something technical.
I write code since forever, addicted to it. I happen to be in a field that pays good money for my addiction. So far, despite the stupidity of the profession, things turn out mostly OK. Why does someone pay me? Don't care. As long as the relationship is beneficial to me, it's OK. I feel I have more in common with starving artists in other fields, than some corporate official looking out for business interests. So I'd be a starving programmer in a parallel world where programming is not a hot profession. Now, if I had my own business, then I brought all these nontechnical issues upon myself. But then, I'll pay myself for whatever reason I want.
One time, it came the day I was supposed to enter the job market. So I looked at what companies - around me and worldwide - are doing, I read the stuff about "solving business problems" instead of "just writing code"... and I realized that if I were to really care about this, I would be unemployable. Because most of the "business needs" in our industry are trivial bullshit stuff that's at best neutral (more often harmful) to society, and only exists to make money for some entrepreneur. I don't give a shit, and will never give a shit about those problems. So - through many years of depression and burnout - I learned to ignore most of the business goals and focus on doing my part the best I can.
For example, right now I'm paid for developing an application that shouldn't really exist in the first place, and makes little sense to anyone - not to developers, not to people who will end up uing it - except the management. But well, management decides. So if I'm making this application anyway, I'm focusing on making it as useful as possible. Management asks for features. I do the ones that make sense and politely suggest changes in the ones that are idiotic. They're happy. I'm paid. When they're not looking, I'm venting out on HackerNews.
--
So yeah, to people constantly writing about focusing on delivering business values: please tell me how to look for values worth delivering, in the sea of moral bankrupcy the current job market is.
Now, if I was a partner in a business with some equity stake, then I would mop the floors if that's what I felt would increase the value of my stake. But as a wage worker, when you tell me to mop the floor, I tell you "that's not my fucking job".
People act in their own self interest. Why is this so god damn difficult to understand? Fuck!
And another thing worth pointing out is: most employers hire you to write code. That's the job spec. So don't be surprised that that's what we end up doing.
And expect those changes to take an hour (maybe two).
Doesn't matter what it does. It is literally impossible to sell even $20 worth of the solution the person advocates. Go ahead: link me to anywhere in the web selling a 5-line bash file without anything else. I'm waiting.
You can do a lot in 5 lines, too. lalalala. waiting. While I wait I think I'll make some money coding something people actually pay for. /s
Seriously though, while the author's point might stand in many sys admin and even systems integration roles - most of the software world actually pays for deliverables: the clearest example of which is consumers doing so. People would rather spend 20 hours cursing, and then give up, rather than pay for a systems integration script that generalizes and solves their problem. It's what the market demands. This article really would make sense if it came from the person paying -- but it doesn't. nobody who is paying actually says the words the article chose for the title. Yes, you are paid to code.
After you write something like that you don't turn around and sell it on the web.
Or when somebody can write a 5-line shell script in Bash that:
a) typical non-programmers can and will use b) produces enough diagnostic information that anybody (programmer or not) can use to troubleshoot when something inevitably goes wrong - whether it's user input, network connectivity, a missing dependency...
I get what he's saying, but he's talking about a pretty small subset of what we really do.
This. This is the thing that took the longest to sink in and had the biggest impact. There were a lot of cool languages, tools, platforms, and systems along the way, and I was stoked picking up each one and coding -- but after decades of that, I realized I was focusing on the wrong thing.
I think the thing that convinced me was when I got to start watching lots of technology teams in the wild across multiple organizations. So many times I would see conversations and tons of problem-solving effort being spent on the tools to solve the problem instead of the problem itself.
A couple of years ago I was teaching tech practices to a team that was deploying on iOS, Droid, and the web. After we went over TDD, ATDD, and the CI/CD pipeline, I emphasized how crucial it was not to silo. When I finished, a young developer took me aside.
"You don't understand. We have coders here who just want to do Java. They want to be the best Java programmers they possibly can be."
I told him that he didn't understand. Nobody gave a rat's ass about people wanting to program Java. They cared about whether the team had both the people and technical skills to solve a problem they have. It would be as if a carpenter refused to work on a cabinet because it wouldn't involve using his favorite hammer. You're focusing on the wrong thing.
Sadly, once you get this, the industry is all too happy to punish you for it. That's because the resume/interview/recruitment world is interested in buzzwords and coolkids tech, not actually whether or not you can make things people want. This means sadly, in a way, if you continue growing, it's entirely possible to "grow out of" programming.
Your insight really hit home. Especially since I've been on a new software dev position for about a month now. This is the overwhelming issue that is already reared its ugly head, is massively frustrating and I feel (nearly) powerless to stop it.
http://benjiweber.co.uk/blog/2016/01/25/why-i-strive-to-be-a...
The company I work for is super successful so there must be something to it.
I sum the quote up as, "Systems are sentient beings like the One True Ring, and they will absorb you. Soon, though you believe you are thinking freely, you will actually be merely a part of the System, thinking what it wants you to think." So true!
But ... Taco Bell programming still creates a new system. That's a flaw in the article's premise.
If you solve a problem by stringing together 11 tools, then yes, you should get some benefits from reusing preexisting tools. But now, you have a system with some rube goldberg characteristics, plus you've written a bunch of "glue code" (which is "new code") in the process.
Those systems can often turn out to be more complex.
Also for orgs that do the developing for other orgs it isn't really optimal to offer the quick and efficient solutions unless competitors are doing the same.
1 instance on aws...sure hope our availability zone stays up next year.
When hardware was expensive the idea was to make everything as tiny and efficient as possible. Now that hardware is cheap the idea is to make everything as scalable as possible so as to take advantage of all that extra hardware you can now afford.
The next phase of this evolution is to go back to making everything tiny and efficient again as we reach the theoretical limits of horizontal scalability. A good way to "force" such practices is to make your developers use single (or just limited) hardware for everything.
I doubt your boss is coming from this angle but I've actually witnessed this put into practice by forcing a small development team to run their code on Raspberry Pis. It really brings home the idea that, "No, really: Your code is slow and inefficient."
It makes people re-think their architectures and often forces them to divide tasks up into smaller pieces that can be written efficiently. Also, nothing says, "ditch your ridiculously complicated and slow build process" than forcing it to run on embedded hardware.
If your build forces a multi-core embedded system with a gig of RAM to thrash and crash you need to re-think things a bit =)
If this were true than 99% of software wouldn't be such crap.