18 ms·

Evil programmer's tip: avoid “easy” things (2016)

517 points by damir 5y ago

le-mark 5y ago
A lot of wisdom here. The hard things are almost always more fun than the easy things anyway. > To get away with postponing, you need an excuse: other supposedly urgent work; This is shockingly easy in “shared resource” environments where team lines blur and management expects people to pitch in “where ever”. Just take on a tasks for manager A and B and play them off of each other.
- mateo411 5y ago
  Yes, there are a lot of dysfunctional organizations out there. That's a strategy that might yield short term financial success and entertainment value, but it's probably not helping out the organization.
  - ExtraE 5y ago
    I mean, outside of small-startup environments, who cares? Do I have a moral responsibility to care? Maybe. Do I have a real reason to care outside of that tenuous-at-best ethical reason? If you believe the author's piece, no.
  - wly_cdgr 5y ago
    That's ok. It's not hard to find organizations to work at such that not helping them out is either not really harming or actually improving the world
  - LordDragonfang 5y ago
    >but it's probably not helping out the organization. If this strategy is useful, the organization doesn't care about you anyway.
  - BeFlatXIII 5y ago
    I’m here to make a buck for myself, not help the organization raise shareholder value.
- jcun4128 5y ago
  It's funny you have this nice paying job but it becomes a lull/drag idk shouldn't complain.
H8crilA 5y ago
This blog is amazing. I currently find myself in some sort of a conflict with management over the classic "new-features vs make the thing stable" situation. Management openly admits to valuing tech debt repayment, reliability etc. but I can clearly tell that it is not what is actually valued. And why shouldn't I just skip code reviews, skip analyzing failure scenarios. Just churn out new shit at an "amazing pace" with little regard to fulfilling the harder part of the target objectives of the system. http://yosefk.com/blog/people-can-read-their-managers-mind.html http://yosefk.com/blog/people-can-read-their-managers-mind.h... We'll try to fix it when shit actually hits the fan, when the harder to achieve properties of the system are considered urgent again :) (Just to make it clear: I am not working on medical devices or power plants or anything of this sort).
Cornpuffs 5y ago
This works until your boss understands software development
- usefulcat 5y ago
  That situation is in the 'good problems to have' category.
  - Cornpuffs 5y ago
    absolutely
- zizee 5y ago
  If your boss understands software development, then the "dangerous" situation of being asked to do "easy" (but actually hard) things disappears, because your boss will understand that the "easy" things are actually hard, and the "hard" things are actually easy.
  - Cornpuffs 5y ago
    I agree! This is the case with my boss and its a great work environment
- rantwasp 5y ago
  spoiler: if your boss understands this they 1) are not doing their jobs 2) they will fail hard if they try to push their own thinking on HOW to do things
  - Cornpuffs 5y ago
    Interesting. To be clear I'm a developer and my boss is a director of application development. He used to be a dev so he understands these kind of issues. If my boss was a product owner or a stakeholder I would not want them mandating random details about how I do things.
- z3t4 5y ago
abraae 5y ago
This is the work of a modern Machiavelli.
andi999 5y ago
Sounds like a normal day in office.
wnevets 5y ago
> Under time pressure, the scope shrinks You may call it evil but I call it building the things that actually need to get done.
- agumonkey 5y ago
  I'd bet a huge amount of "pro skills" is having a sense of balance between time-to-implement / feature-value. And design stuff that allows for slight additions without going full-blown NIH framework
  - Swizec 5y ago
    “How to make this work within constraints” and “When to suggest alternatives with better constraints that require smol tweaks in requirements” is the whole point of engineering. “Build whatever they ask” is … eh it’s not what engineering is about. You have to be a partner, an expert. Can’t expect the suits to know everything, that’s what they hired you for.
    - erdo 5y ago
      So much this
    - agumonkey 5y ago
      The thing is, at least in my experience, until you work for someone (and especially alone) you have no feel for what constraints are. Especially in programming today.. we have almost infinite compute power and storage (unless you develop something very very demanding) so it's so easy to go wild. My only lone "pro" gig (and from scratch) I gained a knowledge about what is critical to make your project coast smoothly and how nothing else matters at all. You want clear / small / predictable changes toward a goal that can make you feel finished and solid rapidly. Unlike the neverending projects reboot with grandiose attempts at pure abstractions, that I used to do.
- bob1029 5y ago
  Simply prioritizing tasks correctly is all you really need to do. If you can't figure out what is important or not, default to order by descending difficulty. Get the team on a call and figure out hardest, 2nd hardest, 3rd hardest, and then assign those tasks. You will likely (but not always) find the trivial, "easy" shit wasn't that valuable to begin with - otherwise it would have been prioritized by the business and have been completed already. There are additional benefits with this approach - If the whole team starts knocking out the scariest shit first, it's like paying off your biggest debt first. The psychological power of that is really hard to overstate in my experience.
tluyben2 5y ago
In my experience these 'evil' things are rather common practice. People do far more nasty stuff to get ahead, all the time. Programmers are no exception.
ghostbrainalpha 5y ago
I love when someone puts this kind of thought and philosophy behind some of the crazy choices we are making subconsciously every day.
simonbarker87 5y ago
At my last job I made a feature to deploy arbitrary user code (most likely a trained model in Python) to a subdomain running a JS server that could take input parameters when called at that URL and would respond with the answer from the model. This effectively cut down DS deployments from potentially days to about 45 seconds. It was seen that be hard and I had a good amount of help from our awesome devops person and worked through a number of issues with the lead dev. When this was delivered everyone loved it, lots of kudos and compliments because it was seen as hard. I felt like a bit of a fraud as I felt I had a lot of help and it really was a team effort, I made efforts to highlight this. I also worked on my own (with the exception of some nginx issues) on a feature to keep an in browser file browse up to date for all users via web sockets. This was really a view on a git repo accessed through the Gitlab api, it was a nightmare to deal with because of the way Git tracks (or doesn’t really) folders. This feature was seen to be easy and I slaved on it for days and eventually weeks because of edge cases and feature creep to no kudos or compliments. Which is fine, it’s my job. It matters, I think, not if the task is easy or hard but if management/product view something as easy or hard.
- version_five 5y ago
  It's sort of like how it's better to be a firefighter than a maintainer, which is guess is the point. The ease may be similar, but coming in to save everyone from an explosion gets you more points than oiling the valve every day so pressure doesn't build up in the first place. It's a cultural issue that is very hard to combat.
  - passivate 5y ago
    Indeed, thank your (figurative and literal) janitors and maintenance staff! :)
  - beebeepka 5y ago
    Indeed. Sometimes the saviour is the one responsible for the disaster but companies also need their heroes or at least that's how I interpret certain management decisions. Been on both sides of the fence.
  - 5y ago
danieldbird 5y ago
Sounds like hard work..
lordleft 5y ago
Whatever one thinks of the techniques recommended in this article, the perils of working on a "easy" but in actuality hard problem are not to be overstated.
- 100011_100001 5y ago
  The dreaded 3 point story that takes 3 weeks. ...yeah been there.
  - phist_mcgee 5y ago
    This is why I always severely overestimate the length of my tickets. 1. I am usually never behind schedule 2. I look like a hero when I deliver on time
deleted 5y ago
[deleted]
jollybean 5y ago
'easy' and 'perceived' as easy are different things. Things that are perceived as hard, usually are way harder, and you're set up to fail. Since corporations don't like failure, even when it's expected, it's a tough choice that mingles up the author's logic. I'd argue the 'easy thing done' counts more because you 'got it done' and the complexity is a second order factor. It's one of the things I'm always on the lookout for actually, is to try to ascertain really what's going on. The added challenge, is that sometimes 'bad devs' make things necessarily complex out of stupidity, and 'brilliant devs' often do the same out of adding on unnecessary complexity. It takes a lot of oversight to tell, and it's almost impossible to guess at from the outside.
quelsolaar 5y ago
I actively try to avoid to do anything the easy way, because I know ill get bored if do. Motivation is the most valuable resource in programming. I rather do something over engineered that I find interesting, then something simple and boring. Even if it takes 3 times the effort, I know ill put more than 3 times the effort in if I'm motivated, and ill end up learning something and ill end up with something I'm proud of, something worth talking about.
- tcoff91 5y ago
  Sounds like you’ll end up with something 3x as hard for future engineers to maintain also.
  - erdo 5y ago
    (Or yourself to maintain in a year's time)
  - TeMPOraL 5y ago
    Beats not doing it at all.
  - JeremyNT 5y ago
    ... but also 3x the job security, perhaps?
  - waynesonfire 5y ago
    Why? You were given no suggestion in which dimenension the complexity was introduced in. Frequently, the better design requires the additional effort. Its the quick hacks and shortcuts that accumulate debt fastest.
- deleted 5y ago
  [deleted]
- amirkdv 5y ago
  I can't tell if this is sarcasm or not. If serious ... This seems like a reckless way of regulating your motivation at work IMO. I don't mean to be snarky. But it really does put a lot of risk and cost on your colleagues, doubly so if you're leading a team, /and/ puts a lot of risk on your own career and reputation. If you need to over-engineer everything to stay motivated, you need a different job. A job where the _problems_ are hard and the challenge is to find simple solutions to them, instead of the other way around.
systemvoltage 5y ago
Easy things appear hard to upper management. Hard times appear to be easy. Then you see a bunch of people getting promoted by working on "hard" things while you are left dealing with "easy" things. Good leadership senses this dichotomy. There are also things you cannot tell anyone in sufficient detail how difficult they are and no matter what you do - they always appear to be easy. Everytime I pickup a hobby, I underestimate it. By a lot. The depth and endeavor for human expertise never ceases to amaze me. You're alone a lot of times and I find solace in the fact that my brain is a machine that takes calories as input and produces heat + code. Might as well try to take on hard things regardless of what others think of it. I'll be left with a real kick of pleasure by solving problems than fake titles obtained by excessive misuse of vocal cords.
postmeta 5y ago
the problem is managers who know a little about programming thinking everything is "easy" and declaring as much to marketing
marto1 5y ago
While I do get the point, I feel like this works only for people having regular jobs, e.g. being paid for their time. If you're a researcher for example bashing at that hard(but often popular) thing will probably yield little to no results. On the other hand going for paths unknown might feel riskier, but has the potential of uncovering low hanging fruit. Just my 2c.
titzer 5y ago
A classic "easy" thing that appears "hard": write a little bit of assembly. Note, a little bit[1]. Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. The key is you need to write and debug a little at a time. Case in point, I wrote an entire Wasm interpreter[2] in x86-64 asm over the past few months. I wrote it a little at a time, had lots of unit tests, and am working in an engine that was already completely functional (with a slower interpreter). [1] If you find yourself writing more than a hundred or so assembly instructions in a sitting, you are going to fail. If you find yourself writing more than a few thousand assembly instructions, total, you have probably have already failed. [2] https://github.com/titzer/wizard-engine/blob/master/src/engine/x86-64/X86_64Interpreter.v3 https://github.com/titzer/wizard-engine/blob/master/src/engi...
- amelius 5y ago
  Isn't it better to write the entire thing in a higher level language like C first, then start optimizing the slow parts e.g. by writing them in assembly?
  - titzer 5y ago
    Sometimes writing asm is just to get access to certain instructions or states not exposed in C. Particularly on embedded platforms. But generally, I agree that you should write most, if not all, in a higher-level language first.
  - tluyben2 5y ago
    For all our embedded work, we first prototype (something we always call a simulator which it kind of is) in typescript (used to be c#), then port to c => if we need 'less' (the c version is too big, too slow etc) we port it to asm. The advantage of this way is that we already know it meets the demands of the business (because we fleshed that out with the typescript version) and we have a low level version (c) that corresponds in functionality as we can test the 2 versions in the same way. Moving to asm is still a pain, but far less painful than other ways we tried in the past (like when I did a lot of straight to asm in the 80s, which was very painful, but there was no real way, except for some algorithms, to do the 'simulator' step here).
jofer 5y ago
Ouch. This hits close to home. I _constantly_ get passed over for the interesting work, despite being _extremely_ qualified for it. (e.g. I keep getting told I don't "have a scientific background", so I'm not qualified to work on problem X, despite the fact that I have a PhD in the field and extensive experience on closely related problems) It's because I'm seen as a technician, not an engineer or a scientist. That's because I'm the person everyone picks for the "hey, just whip up this quick demo / generate this report / prototype this idea for me", and therefore I get critiqued when it's not fast enough / polished enough, despite it being a "drop everything and have this done by 10pm" situation every time. The big things I've accomplished, other people have _always_ gotten credit for. The things that fail, I get the blame for. So serious advice from someone who's too old to change it now: SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!! Once you start, it's a trap that's really hard to get out of and gets you nowhere career wise.
- BurningFrog 5y ago
  > SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!! Or find new management, if this is a consistent problem. Unless you happen to be the management hiring boss, that means finding a different place to work.
  - junon 5y ago
    This is really easy to say, but having done pretty much exactly this for ages, finding management that doesn't take advantage of you in this regard is really rare.
    - abledon 5y ago
      what industry/country are you in?
      - junon 5y ago
        Software engineering, have been doing it professionally for over 11 years.
pronoiac 5y ago
"We do these things not because they were easy, but because we thought they would be easy."
passivate 5y ago
Heh, I think this applies to pretty much everything and everyone. For most people, anything you haven't done yourself or know in great detail, you will not be able to gauge how hard it is. And sometimes what people are calling hard is actually very easy for a certain set of people. So its all relative anyway.
deleted 5y ago
[deleted]
markus_zhang 5y ago
I think most people get into hard "easy" problems not because they want, but because those problems usually have a lot of opening positions. Low level programming, on the other side, does not have a lot of openings. The majority have to do those hard "easy" problems for their life.
SavantIdiot 5y ago
What the author is outlining is a management paradox when managing by indicators, combined with some egotrippin'. It is hard to punish people for working hard and fixing something, when they are fixing something they created that was crappy from the start! And then the team that is highly-tuned and made a perfect design from the start shows very little improvement because it is already perfect. The indicators flip the script and make it hard to decide who actually deserves accolades. The correct answer is that they both do: one team for figuring out their mess, the other team for executing flawlessly. But the flawless people, in my experience, tend to have big egos and are offended by the seemingly equitable treatment. The part about ego trip is the "always looking out for yourself." On the one hand, you have to promote yourself, on the other hand, you're part of a team. And manipulating the system to make to make sure you get preferred assignments backfires spectacularly. Which is why those folks tend to switch companies a lot. I'm ambivalent about this. It can be taken as some tips as how to be be assertive by not getting shafted by evildoers like the author (remember that debate from last week on HN?), which are healthy. But there's also a lot of "me first" that'll get you shivved in the long run.
- razzimatazz 5y ago
  My favorite is the times when I have dived in to fix performance of the system, found the place where I or a team mate left in a terribly unnecessary loop or increased complexity, quickly fix that and report back the great success in improving performance! Great indicator there for management. I think the person/team following such a path does deserve accolades but if their ego blocks them from admitting honestly how difficult the work was, others will sense (maybe not management) the dishonesty sooner or later and problems will eventually develop. I always give my team mates accolades and offer them excuses when they've messed up: "we were really busy that week", "its easy to forget to bump the minor version", "that manual testing work is tough". If they choose to ignore the offered excuse and go silent with their ego I think it stands out sorely over time. If they accept it then we all know what we have to improve on next time.
  - SavantIdiot 5y ago
    > I always give my team mates accolades and offer them excuses when they've messed up: " I like that a lot! Engineers almost always know when they've screwed up. No need to thunk people over the head: I've been thunked (and screamed at, and threatened, and humiliated) so many times that I made sure that bullshit ended with my management style.* Unless they do it repeatedly, or are totally unaware... those are some of the worst types of situations for me personally as a manager. * to the best of my knowledge: blindspots abound, esp. across cultures.
Fiahil 5y ago
Since I started working as a “consultant”, I started using the exact same Evildoer tricks ! I’ve said “No” to partners coming with easy & urgent requests, just because I wasn’t feeling like dropping my work and doing these. To the juniors’ disbelief, I _gained_ their respect. This is also how I never got caught with the “can you stay all night/all weekend and try to get this done before monday ? Our boss just asked for it..” song. Nope, he’s just being evil. I have other plan, good luck.
- quickthrower2 5y ago
  I imagine this works as long as you can say no, requiring good financial management and marketing skills. Easy to say no when you are turning away work.
  - krab 5y ago
    It works both ways as a positive feedback loop.
  - Fiahil 5y ago
    That's also another positive feedback loop between being "evil" and a consultant job. If your work is perceived as "hard" and you let your client do the "easy" part, then you can increase your fees (bigger impact, and more ownership for them). If your fees are higher than normal, then your client doesn't want to bother you with the "easy" stuff. You get hired to do the "hard" things. Doing "hard" things often involve saying no to spurious/out of scope requests. Etc etc...
nlawalker 5y ago
> One thing you want to prevent is people learning to remind you earlier. The way to accomplish it is being very nice when they come late. If people feel punished for reminding too late, they'll come earlier next time, and in a vengeful mood, so with more needless tasks. But if they're late and you eagerly "try to do the best under the circumstances", not only do you put yourself under the spotlight as a patriotic hero, you move the forgetful culprit out of the spotlight. So they'll form a rosy memory of the incident, and not learn the value of coming earlier – precisely what we want. This speaks to another effective career strategy, which is to focus on making the people you interact with feel good - about you, the situation, the company you work for, and especially about themselves. This is particularly important with first impressions and for people with whom you don't work very often. "I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." - Maya Angelou
karmakaze 5y ago
I have different attitudes around things perceived as easy or hard. Things that are considered by many to be easy I pay extra attention to looking for details that may show it's not really easy to do properly. Hard things I think and rethink to see if there's an easy approach or conceptualization that does less or something different achieving the same end goal. As others have said, I also gravitate toward the hard stuff because it's more interesting. And if there's a complicated way of automating or otherwise have the machine do the work instead of myself, even if it takes longer and may only do once is still a good learning/hacking opportunity. Sometimes cool stuff comes out, like a partial Swift -> Java, or Java to C++ translator because I don't want to rewrite a suite of tests.
chrisweekly 5y ago
This is hilarious, and cynical, and contains a legit kernel of wisdom.
- env123 5y ago
  Eh, not really, it sounds like one of those Robert Greene BS books. Sounds exciting when you're young and inexperienced, but tiresome when you're older and actually wise
  - chrisweekly 5y ago
    Ha! Did your comment make you feel better about yourself? Was it representative of the kind of wisdom you value? Because it came across as a misdirected, failed attempt at an insult.
jonplackett 5y ago
The Elon Musk Doctrine
ineedasername 5y ago
Maybe? Sometimes? But the article seems to imply a very high level of control over the tasks & projects that come your way. In reality, I (and probably a lot of people) don't have that choice. I end up looking like a hero when I can deliver quickly on a "hard" easy thing, and look like I'm slacking off when an "easy" hard thing comes my way. Fortunately I have had bosses who listen when I explain the difficulties of a project, but they still get frustrated on occasion when an ostensibly simply task snowballs into something massive more complex once you dig into the details.
code_duck 5y ago
I’ve had first-hand experience confirming this and another field. Sometime in my 20 years of artistic glassblowing, I believed that people where to find it moderately impressive if I made intermediate level work very solidly with a flourish. I thought this was an alternative to making work that was more overtly at a higher skill level, and a better choice than making less solid work reaching above my skill level. It turns out that as the article states, working on anything cutting edge, especially ambitious publicized projects, would have been much better for gaining notoriety.
maerF0x0 5y ago
at a job once we had a programmer do a gratuitously bad implementation that wasted over $400k of cloud spend. They got promoted for fixing it the following half. My project that quarter continues to run multiple years later without a hiccup. Much like they do with me, they often forget it exists. Law 6 Court attention at all costs - https://alexanderemmanual.medium.com/law-6-court-attention-at-all-costs-63132007d214 https://alexanderemmanual.medium.com/law-6-court-attention-a...
mdausmann 5y ago
This is bullshit. There are any number of 'easy' things that need to get done. The discipline in being a grown up no bullshit engineer is to do all of these easy things well, without errors and with appropriate test coverage. If you are in my team, I will appreciate and reward your maturity and attention to detail. What I don't want is somebody who always want's to work on the 'interesting' problem at the expense of the small stuff. grow up.
- Subsentient 5y ago
  I agree with you, though sadly HN doesn't. Some days you're just beating your skull against a brick wall recompiling 3rd party libraries till 5pm, some days you get to write the big exciting part. That's life. That's the job. Accept it or move on.
- oytis 5y ago
  You might appreciate it but not everyone does. Also there is a Matthew effect in play - the more boring stuff you do the less chance you have to do something interesting in the future. Because everyone on the market wants you to have experience with things similar to what they are about assign you to.
nly 5y ago
Complexity of tasks doesn't matter to the business, only the impact of completing them. If a client wants X or won't sign a contract worth $Y then the tasks to complete X become valuable regardless of their complexity.
teambob 5y ago
I learned this long ago. Along with: you will never be thanked for getting a garbage project across the line. You will be thanked more for having a small part in a good project than being the hero on a garbage project.
christophergs 5y ago
Obligatory XKCD which brilliantly captures how management can fail to distinguish easy/hard tasks: https://xkcd.com/1425/ https://xkcd.com/1425/
qaq 5y ago
One thing that annoys me is that if you carefully craft a complex subsystem that behaves well in prod that does not get noticed much. On the other hand a quickly thrown together something that requires heroic efforts to keep running and make stable might get much more noticed.
robertwt7 5y ago
> So they'll form a rosy memory of the incident, and not learn the value of coming earlier – precisely what we want. OMG this is sooo true, my first company does not have any product manager or project manager. My boss who is one of the management always try to "impress" other management by saying yes to some stuff that they challenge him: "can you do it?", then he would say "yes it will be finished in 2-3 days", and then he would come to me and say "we need to impress them", again and again until i'm sick of it because we just went away from our sprint and planned projects. Stupidly, I just did it again and again. Luckily I quit before I hated him, but then my teammates are still there. best of luck tot hem
ffitch 5y ago
For me, it works the same way even if others are not involved. If I do a tricky thing in a matter of hours because I got lucky I tend to feel happier about it compared to if I’ve done a simple but mundane thing over the weekend. Perceived complexion brings excitement.
quickthrower2 5y ago
Coincidently I was thinking the other day if I learn kubernetes, azure services and networking to a decent level, I might have a nice source of easy hard things in the future (most coders don’t seem super keen on this kind of stuff)
oreally 5y ago
I could be more productive using my own frameworks to build stuff but I don't think I'll get paid for it though. Such is life.
TrispusAttucks 5y ago
"If you do too much people get dependent on you. And if you do nothing, they lose hope…when you do things right, people won’t be sure you’ve done anything at all.” ~ God (Futurama)
qwertywert_ 5y ago
Yea maybe if managers didn't pressure so hard on new features when they know 100% that there are so many bugs needing fixing + tests need writing, and general stability issues. Shit will hit the fan but that's how they are directing the course of the ship, early in my career I just have to go with it right now It is not worth it for me to try doing the "easy" things when they aren't valued.. Working like this is too stressful though even if you look like a hero.
teekert 5y ago
I really like this advice and always op for the hard way, the way that solves things preferably for many others, once and for all in an elegant way. At work, you have time to dive into stuff, for hours on end with little interruption. Very different from at home, with your hobby projects. I see work as a place where I do indeed solve very hard problems because I just have a massive amount of time and focus to spend there.
Rastonbury 5y ago
Effort estimation in agile development is supposed to solve this right? Does it not in practise? I'm not a developer, I've just heard of agile so I don't really know how its actually done in a big software org
- mjohn 5y ago
  No, because it's often very hard to estimate until you're actually working on something. It's common to get a consensus estimate that something is "easy" only for some poor developer to be left with something that is "hard" and takes much longer than estimated. Also, something might genuinely be easy for someone who has worked on that part of the codebase before. But it could take someone new a long time to get up to speed, again making that developer look bad (this is not to advocate that only devs familiar with the code should work on it - you want to spread the knowledge around).
jb3689 5y ago
Working on hard problems isn’t always a rewarding path. I’ve seen plenty of very senior engineers get sucked into difficult problems with no additional resourcing only to be all but forgotten by the rest of the team. I agree that working on easy problems is not worth your time though
yobbo 5y ago
> and you let them fail a few times, and you wait until they come back with a readjusted attitude - that's evil. What, no? Letting ignorant people fall on their knives is /doing good/. It's the best way of learning. Letting ignorant people harm others - that's evil.
aliswe 5y ago
Am I the only one having a hard time understanding what he's saying? Somehow it just feels like a hodgepodge of words.

517 points by damir 5y ago

A lot of wisdom here. The hard things are almost always more fun than the easy things anyway. > To get away with postponing, you need an excuse: other supposedly urgent work; This is shockingly easy in “shared resource” environments where team lines blur and management expects people to pitch in “where ever”. Just take on a tasks for manager A and B and play them off of each other.

mateo411 5y ago
Yes, there are a lot of dysfunctional organizations out there. That's a strategy that might yield short term financial success and entertainment value, but it's probably not helping out the organization.
- ExtraE 5y ago
  I mean, outside of small-startup environments, who cares? Do I have a moral responsibility to care? Maybe. Do I have a real reason to care outside of that tenuous-at-best ethical reason? If you believe the author's piece, no.
- wly_cdgr 5y ago
  That's ok. It's not hard to find organizations to work at such that not helping them out is either not really harming or actually improving the world
- LordDragonfang 5y ago
  >but it's probably not helping out the organization. If this strategy is useful, the organization doesn't care about you anyway.
- BeFlatXIII 5y ago
  I’m here to make a buck for myself, not help the organization raise shareholder value.
jcun4128 5y ago
It's funny you have this nice paying job but it becomes a lull/drag idk shouldn't complain.

H8crilA 5y ago

This blog is amazing. I currently find myself in some sort of a conflict with management over the classic "new-features vs make the thing stable" situation. Management openly admits to valuing tech debt repayment, reliability etc. but I can clearly tell that it is not what is actually valued. And why shouldn't I just skip code reviews, skip analyzing failure scenarios. Just churn out new shit at an "amazing pace" with little regard to fulfilling the harder part of the target objectives of the system. http://yosefk.com/blog/people-can-read-their-managers-mind.html http://yosefk.com/blog/people-can-read-their-managers-mind.h... We'll try to fix it when shit actually hits the fan, when the harder to achieve properties of the system are considered urgent again :) (Just to make it clear: I am not working on medical devices or power plants or anything of this sort).

Cornpuffs 5y ago

This works until your boss understands software development

usefulcat 5y ago
That situation is in the 'good problems to have' category.
- Cornpuffs 5y ago
  absolutely
zizee 5y ago
If your boss understands software development, then the "dangerous" situation of being asked to do "easy" (but actually hard) things disappears, because your boss will understand that the "easy" things are actually hard, and the "hard" things are actually easy.
- Cornpuffs 5y ago
  I agree! This is the case with my boss and its a great work environment
rantwasp 5y ago
spoiler: if your boss understands this they 1) are not doing their jobs 2) they will fail hard if they try to push their own thinking on HOW to do things
- Cornpuffs 5y ago
  Interesting. To be clear I'm a developer and my boss is a director of application development. He used to be a dev so he understands these kind of issues. If my boss was a product owner or a stakeholder I would not want them mandating random details about how I do things.
z3t4 5y ago

abraae 5y ago

This is the work of a modern Machiavelli.

andi999 5y ago

Sounds like a normal day in office.

wnevets 5y ago

> Under time pressure, the scope shrinks You may call it evil but I call it building the things that actually need to get done.

agumonkey 5y ago
I'd bet a huge amount of "pro skills" is having a sense of balance between time-to-implement / feature-value. And design stuff that allows for slight additions without going full-blown NIH framework
- Swizec 5y ago
  “How to make this work within constraints” and “When to suggest alternatives with better constraints that require smol tweaks in requirements” is the whole point of engineering. “Build whatever they ask” is … eh it’s not what engineering is about. You have to be a partner, an expert. Can’t expect the suits to know everything, that’s what they hired you for.
  - erdo 5y ago
    So much this
  - agumonkey 5y ago
    The thing is, at least in my experience, until you work for someone (and especially alone) you have no feel for what constraints are. Especially in programming today.. we have almost infinite compute power and storage (unless you develop something very very demanding) so it's so easy to go wild. My only lone "pro" gig (and from scratch) I gained a knowledge about what is critical to make your project coast smoothly and how nothing else matters at all. You want clear / small / predictable changes toward a goal that can make you feel finished and solid rapidly. Unlike the neverending projects reboot with grandiose attempts at pure abstractions, that I used to do.
bob1029 5y ago
Simply prioritizing tasks correctly is all you really need to do. If you can't figure out what is important or not, default to order by descending difficulty. Get the team on a call and figure out hardest, 2nd hardest, 3rd hardest, and then assign those tasks. You will likely (but not always) find the trivial, "easy" shit wasn't that valuable to begin with - otherwise it would have been prioritized by the business and have been completed already. There are additional benefits with this approach - If the whole team starts knocking out the scariest shit first, it's like paying off your biggest debt first. The psychological power of that is really hard to overstate in my experience.

tluyben2 5y ago

In my experience these 'evil' things are rather common practice. People do far more nasty stuff to get ahead, all the time. Programmers are no exception.

ghostbrainalpha 5y ago

I love when someone puts this kind of thought and philosophy behind some of the crazy choices we are making subconsciously every day.

simonbarker87 5y ago

At my last job I made a feature to deploy arbitrary user code (most likely a trained model in Python) to a subdomain running a JS server that could take input parameters when called at that URL and would respond with the answer from the model. This effectively cut down DS deployments from potentially days to about 45 seconds. It was seen that be hard and I had a good amount of help from our awesome devops person and worked through a number of issues with the lead dev. When this was delivered everyone loved it, lots of kudos and compliments because it was seen as hard. I felt like a bit of a fraud as I felt I had a lot of help and it really was a team effort, I made efforts to highlight this. I also worked on my own (with the exception of some nginx issues) on a feature to keep an in browser file browse up to date for all users via web sockets. This was really a view on a git repo accessed through the Gitlab api, it was a nightmare to deal with because of the way Git tracks (or doesn’t really) folders. This feature was seen to be easy and I slaved on it for days and eventually weeks because of edge cases and feature creep to no kudos or compliments. Which is fine, it’s my job. It matters, I think, not if the task is easy or hard but if management/product view something as easy or hard.

version_five 5y ago
It's sort of like how it's better to be a firefighter than a maintainer, which is guess is the point. The ease may be similar, but coming in to save everyone from an explosion gets you more points than oiling the valve every day so pressure doesn't build up in the first place. It's a cultural issue that is very hard to combat.
- passivate 5y ago
  Indeed, thank your (figurative and literal) janitors and maintenance staff! :)
- beebeepka 5y ago
  Indeed. Sometimes the saviour is the one responsible for the disaster but companies also need their heroes or at least that's how I interpret certain management decisions. Been on both sides of the fence.
- 5y ago

danieldbird 5y ago

Sounds like hard work..

lordleft 5y ago

Whatever one thinks of the techniques recommended in this article, the perils of working on a "easy" but in actuality hard problem are not to be overstated.

100011_100001 5y ago
The dreaded 3 point story that takes 3 weeks. ...yeah been there.
- phist_mcgee 5y ago
  This is why I always severely overestimate the length of my tickets. 1. I am usually never behind schedule 2. I look like a hero when I deliver on time

deleted 5y ago

[deleted]

jollybean 5y ago

'easy' and 'perceived' as easy are different things. Things that are perceived as hard, usually are way harder, and you're set up to fail. Since corporations don't like failure, even when it's expected, it's a tough choice that mingles up the author's logic. I'd argue the 'easy thing done' counts more because you 'got it done' and the complexity is a second order factor. It's one of the things I'm always on the lookout for actually, is to try to ascertain really what's going on. The added challenge, is that sometimes 'bad devs' make things necessarily complex out of stupidity, and 'brilliant devs' often do the same out of adding on unnecessary complexity. It takes a lot of oversight to tell, and it's almost impossible to guess at from the outside.

quelsolaar 5y ago

I actively try to avoid to do anything the easy way, because I know ill get bored if do. Motivation is the most valuable resource in programming. I rather do something over engineered that I find interesting, then something simple and boring. Even if it takes 3 times the effort, I know ill put more than 3 times the effort in if I'm motivated, and ill end up learning something and ill end up with something I'm proud of, something worth talking about.

tcoff91 5y ago
Sounds like you’ll end up with something 3x as hard for future engineers to maintain also.
- erdo 5y ago
  (Or yourself to maintain in a year's time)
- TeMPOraL 5y ago
  Beats not doing it at all.
- JeremyNT 5y ago
  ... but also 3x the job security, perhaps?
- waynesonfire 5y ago
  Why? You were given no suggestion in which dimenension the complexity was introduced in. Frequently, the better design requires the additional effort. Its the quick hacks and shortcuts that accumulate debt fastest.
deleted 5y ago
[deleted]
amirkdv 5y ago
I can't tell if this is sarcasm or not. If serious ... This seems like a reckless way of regulating your motivation at work IMO. I don't mean to be snarky. But it really does put a lot of risk and cost on your colleagues, doubly so if you're leading a team, /and/ puts a lot of risk on your own career and reputation. If you need to over-engineer everything to stay motivated, you need a different job. A job where the _problems_ are hard and the challenge is to find simple solutions to them, instead of the other way around.

systemvoltage 5y ago

Easy things appear hard to upper management. Hard times appear to be easy. Then you see a bunch of people getting promoted by working on "hard" things while you are left dealing with "easy" things. Good leadership senses this dichotomy. There are also things you cannot tell anyone in sufficient detail how difficult they are and no matter what you do - they always appear to be easy. Everytime I pickup a hobby, I underestimate it. By a lot. The depth and endeavor for human expertise never ceases to amaze me. You're alone a lot of times and I find solace in the fact that my brain is a machine that takes calories as input and produces heat + code. Might as well try to take on hard things regardless of what others think of it. I'll be left with a real kick of pleasure by solving problems than fake titles obtained by excessive misuse of vocal cords.

postmeta 5y ago

the problem is managers who know a little about programming thinking everything is "easy" and declaring as much to marketing

marto1 5y ago

While I do get the point, I feel like this works only for people having regular jobs, e.g. being paid for their time. If you're a researcher for example bashing at that hard(but often popular) thing will probably yield little to no results. On the other hand going for paths unknown might feel riskier, but has the potential of uncovering low hanging fruit. Just my 2c.

titzer 5y ago

A classic "easy" thing that appears "hard": write a little bit of assembly. Note, a little bit[1]. Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. The key is you need to write and debug a little at a time. Case in point, I wrote an entire Wasm interpreter[2] in x86-64 asm over the past few months. I wrote it a little at a time, had lots of unit tests, and am working in an engine that was already completely functional (with a slower interpreter). [1] If you find yourself writing more than a hundred or so assembly instructions in a sitting, you are going to fail. If you find yourself writing more than a few thousand assembly instructions, total, you have probably have already failed. [2] https://github.com/titzer/wizard-engine/blob/master/src/engine/x86-64/X86_64Interpreter.v3 https://github.com/titzer/wizard-engine/blob/master/src/engi...

amelius 5y ago
Isn't it better to write the entire thing in a higher level language like C first, then start optimizing the slow parts e.g. by writing them in assembly?
- titzer 5y ago
  Sometimes writing asm is just to get access to certain instructions or states not exposed in C. Particularly on embedded platforms. But generally, I agree that you should write most, if not all, in a higher-level language first.
- tluyben2 5y ago
  For all our embedded work, we first prototype (something we always call a simulator which it kind of is) in typescript (used to be c#), then port to c => if we need 'less' (the c version is too big, too slow etc) we port it to asm. The advantage of this way is that we already know it meets the demands of the business (because we fleshed that out with the typescript version) and we have a low level version (c) that corresponds in functionality as we can test the 2 versions in the same way. Moving to asm is still a pain, but far less painful than other ways we tried in the past (like when I did a lot of straight to asm in the 80s, which was very painful, but there was no real way, except for some algorithms, to do the 'simulator' step here).

jofer 5y ago

Ouch. This hits close to home. I _constantly_ get passed over for the interesting work, despite being _extremely_ qualified for it. (e.g. I keep getting told I don't "have a scientific background", so I'm not qualified to work on problem X, despite the fact that I have a PhD in the field and extensive experience on closely related problems) It's because I'm seen as a technician, not an engineer or a scientist. That's because I'm the person everyone picks for the "hey, just whip up this quick demo / generate this report / prototype this idea for me", and therefore I get critiqued when it's not fast enough / polished enough, despite it being a "drop everything and have this done by 10pm" situation every time. The big things I've accomplished, other people have _always_ gotten credit for. The things that fail, I get the blame for. So serious advice from someone who's too old to change it now: SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!! Once you start, it's a trap that's really hard to get out of and gets you nowhere career wise.

BurningFrog 5y ago
> SAY NO TO URGENT ONE-OFF REQUESTS FROM MANAGEMENT!!! Or find new management, if this is a consistent problem. Unless you happen to be the management hiring boss, that means finding a different place to work.
- junon 5y ago
  This is really easy to say, but having done pretty much exactly this for ages, finding management that doesn't take advantage of you in this regard is really rare.
  - abledon 5y ago
    what industry/country are you in?
    - junon 5y ago
      Software engineering, have been doing it professionally for over 11 years.

pronoiac 5y ago

"We do these things not because they were easy, but because we thought they would be easy."

passivate 5y ago

Heh, I think this applies to pretty much everything and everyone. For most people, anything you haven't done yourself or know in great detail, you will not be able to gauge how hard it is. And sometimes what people are calling hard is actually very easy for a certain set of people. So its all relative anyway.

deleted 5y ago

[deleted]

markus_zhang 5y ago

I think most people get into hard "easy" problems not because they want, but because those problems usually have a lot of opening positions. Low level programming, on the other side, does not have a lot of openings. The majority have to do those hard "easy" problems for their life.

SavantIdiot 5y ago

What the author is outlining is a management paradox when managing by indicators, combined with some egotrippin'. It is hard to punish people for working hard and fixing something, when they are fixing something they created that was crappy from the start! And then the team that is highly-tuned and made a perfect design from the start shows very little improvement because it is already perfect. The indicators flip the script and make it hard to decide who actually deserves accolades. The correct answer is that they both do: one team for figuring out their mess, the other team for executing flawlessly. But the flawless people, in my experience, tend to have big egos and are offended by the seemingly equitable treatment. The part about ego trip is the "always looking out for yourself." On the one hand, you have to promote yourself, on the other hand, you're part of a team. And manipulating the system to make to make sure you get preferred assignments backfires spectacularly. Which is why those folks tend to switch companies a lot. I'm ambivalent about this. It can be taken as some tips as how to be be assertive by not getting shafted by evildoers like the author (remember that debate from last week on HN?), which are healthy. But there's also a lot of "me first" that'll get you shivved in the long run.

razzimatazz 5y ago
My favorite is the times when I have dived in to fix performance of the system, found the place where I or a team mate left in a terribly unnecessary loop or increased complexity, quickly fix that and report back the great success in improving performance! Great indicator there for management. I think the person/team following such a path does deserve accolades but if their ego blocks them from admitting honestly how difficult the work was, others will sense (maybe not management) the dishonesty sooner or later and problems will eventually develop. I always give my team mates accolades and offer them excuses when they've messed up: "we were really busy that week", "its easy to forget to bump the minor version", "that manual testing work is tough". If they choose to ignore the offered excuse and go silent with their ego I think it stands out sorely over time. If they accept it then we all know what we have to improve on next time.
- SavantIdiot 5y ago
  > I always give my team mates accolades and offer them excuses when they've messed up: " I like that a lot! Engineers almost always know when they've screwed up. No need to thunk people over the head: I've been thunked (and screamed at, and threatened, and humiliated) so many times that I made sure that bullshit ended with my management style.* Unless they do it repeatedly, or are totally unaware... those are some of the worst types of situations for me personally as a manager. * to the best of my knowledge: blindspots abound, esp. across cultures.

Fiahil 5y ago

Since I started working as a “consultant”, I started using the exact same Evildoer tricks ! I’ve said “No” to partners coming with easy & urgent requests, just because I wasn’t feeling like dropping my work and doing these. To the juniors’ disbelief, I _gained_ their respect. This is also how I never got caught with the “can you stay all night/all weekend and try to get this done before monday ? Our boss just asked for it..” song. Nope, he’s just being evil. I have other plan, good luck.

quickthrower2 5y ago
I imagine this works as long as you can say no, requiring good financial management and marketing skills. Easy to say no when you are turning away work.
- krab 5y ago
  It works both ways as a positive feedback loop.
- Fiahil 5y ago
  That's also another positive feedback loop between being "evil" and a consultant job. If your work is perceived as "hard" and you let your client do the "easy" part, then you can increase your fees (bigger impact, and more ownership for them). If your fees are higher than normal, then your client doesn't want to bother you with the "easy" stuff. You get hired to do the "hard" things. Doing "hard" things often involve saying no to spurious/out of scope requests. Etc etc...

nlawalker 5y ago

> One thing you want to prevent is people learning to remind you earlier. The way to accomplish it is being very nice when they come late. If people feel punished for reminding too late, they'll come earlier next time, and in a vengeful mood, so with more needless tasks. But if they're late and you eagerly "try to do the best under the circumstances", not only do you put yourself under the spotlight as a patriotic hero, you move the forgetful culprit out of the spotlight. So they'll form a rosy memory of the incident, and not learn the value of coming earlier – precisely what we want. This speaks to another effective career strategy, which is to focus on making the people you interact with feel good - about you, the situation, the company you work for, and especially about themselves. This is particularly important with first impressions and for people with whom you don't work very often. "I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." - Maya Angelou

karmakaze 5y ago

I have different attitudes around things perceived as easy or hard. Things that are considered by many to be easy I pay extra attention to looking for details that may show it's not really easy to do properly. Hard things I think and rethink to see if there's an easy approach or conceptualization that does less or something different achieving the same end goal. As others have said, I also gravitate toward the hard stuff because it's more interesting. And if there's a complicated way of automating or otherwise have the machine do the work instead of myself, even if it takes longer and may only do once is still a good learning/hacking opportunity. Sometimes cool stuff comes out, like a partial Swift -> Java, or Java to C++ translator because I don't want to rewrite a suite of tests.

chrisweekly 5y ago

This is hilarious, and cynical, and contains a legit kernel of wisdom.

env123 5y ago
Eh, not really, it sounds like one of those Robert Greene BS books. Sounds exciting when you're young and inexperienced, but tiresome when you're older and actually wise
- chrisweekly 5y ago
  Ha! Did your comment make you feel better about yourself? Was it representative of the kind of wisdom you value? Because it came across as a misdirected, failed attempt at an insult.

jonplackett 5y ago

The Elon Musk Doctrine

ineedasername 5y ago

Maybe? Sometimes? But the article seems to imply a very high level of control over the tasks & projects that come your way. In reality, I (and probably a lot of people) don't have that choice. I end up looking like a hero when I can deliver quickly on a "hard" easy thing, and look like I'm slacking off when an "easy" hard thing comes my way. Fortunately I have had bosses who listen when I explain the difficulties of a project, but they still get frustrated on occasion when an ostensibly simply task snowballs into something massive more complex once you dig into the details.

code_duck 5y ago

I’ve had first-hand experience confirming this and another field. Sometime in my 20 years of artistic glassblowing, I believed that people where to find it moderately impressive if I made intermediate level work very solidly with a flourish. I thought this was an alternative to making work that was more overtly at a higher skill level, and a better choice than making less solid work reaching above my skill level. It turns out that as the article states, working on anything cutting edge, especially ambitious publicized projects, would have been much better for gaining notoriety.

maerF0x0 5y ago

at a job once we had a programmer do a gratuitously bad implementation that wasted over $400k of cloud spend. They got promoted for fixing it the following half. My project that quarter continues to run multiple years later without a hiccup. Much like they do with me, they often forget it exists. Law 6 Court attention at all costs - https://alexanderemmanual.medium.com/law-6-court-attention-at-all-costs-63132007d214 https://alexanderemmanual.medium.com/law-6-court-attention-a...

mdausmann 5y ago

This is bullshit. There are any number of 'easy' things that need to get done. The discipline in being a grown up no bullshit engineer is to do all of these easy things well, without errors and with appropriate test coverage. If you are in my team, I will appreciate and reward your maturity and attention to detail. What I don't want is somebody who always want's to work on the 'interesting' problem at the expense of the small stuff. grow up.

Subsentient 5y ago
I agree with you, though sadly HN doesn't. Some days you're just beating your skull against a brick wall recompiling 3rd party libraries till 5pm, some days you get to write the big exciting part. That's life. That's the job. Accept it or move on.
oytis 5y ago
You might appreciate it but not everyone does. Also there is a Matthew effect in play - the more boring stuff you do the less chance you have to do something interesting in the future. Because everyone on the market wants you to have experience with things similar to what they are about assign you to.

nly 5y ago

Complexity of tasks doesn't matter to the business, only the impact of completing them. If a client wants X or won't sign a contract worth $Y then the tasks to complete X become valuable regardless of their complexity.

teambob 5y ago

I learned this long ago. Along with: you will never be thanked for getting a garbage project across the line. You will be thanked more for having a small part in a good project than being the hero on a garbage project.

christophergs 5y ago

Obligatory XKCD which brilliantly captures how management can fail to distinguish easy/hard tasks: https://xkcd.com/1425/ https://xkcd.com/1425/

qaq 5y ago

One thing that annoys me is that if you carefully craft a complex subsystem that behaves well in prod that does not get noticed much. On the other hand a quickly thrown together something that requires heroic efforts to keep running and make stable might get much more noticed.

robertwt7 5y ago

> So they'll form a rosy memory of the incident, and not learn the value of coming earlier – precisely what we want. OMG this is sooo true, my first company does not have any product manager or project manager. My boss who is one of the management always try to "impress" other management by saying yes to some stuff that they challenge him: "can you do it?", then he would say "yes it will be finished in 2-3 days", and then he would come to me and say "we need to impress them", again and again until i'm sick of it because we just went away from our sprint and planned projects. Stupidly, I just did it again and again. Luckily I quit before I hated him, but then my teammates are still there. best of luck tot hem

ffitch 5y ago

For me, it works the same way even if others are not involved. If I do a tricky thing in a matter of hours because I got lucky I tend to feel happier about it compared to if I’ve done a simple but mundane thing over the weekend. Perceived complexion brings excitement.

quickthrower2 5y ago

Coincidently I was thinking the other day if I learn kubernetes, azure services and networking to a decent level, I might have a nice source of easy hard things in the future (most coders don’t seem super keen on this kind of stuff)

oreally 5y ago

I could be more productive using my own frameworks to build stuff but I don't think I'll get paid for it though. Such is life.

TrispusAttucks 5y ago

"If you do too much people get dependent on you. And if you do nothing, they lose hope…when you do things right, people won’t be sure you’ve done anything at all.” ~ God (Futurama)

qwertywert_ 5y ago

Yea maybe if managers didn't pressure so hard on new features when they know 100% that there are so many bugs needing fixing + tests need writing, and general stability issues. Shit will hit the fan but that's how they are directing the course of the ship, early in my career I just have to go with it right now It is not worth it for me to try doing the "easy" things when they aren't valued.. Working like this is too stressful though even if you look like a hero.

teekert 5y ago

I really like this advice and always op for the hard way, the way that solves things preferably for many others, once and for all in an elegant way. At work, you have time to dive into stuff, for hours on end with little interruption. Very different from at home, with your hobby projects. I see work as a place where I do indeed solve very hard problems because I just have a massive amount of time and focus to spend there.

Rastonbury 5y ago

Effort estimation in agile development is supposed to solve this right? Does it not in practise? I'm not a developer, I've just heard of agile so I don't really know how its actually done in a big software org

mjohn 5y ago
No, because it's often very hard to estimate until you're actually working on something. It's common to get a consensus estimate that something is "easy" only for some poor developer to be left with something that is "hard" and takes much longer than estimated. Also, something might genuinely be easy for someone who has worked on that part of the codebase before. But it could take someone new a long time to get up to speed, again making that developer look bad (this is not to advocate that only devs familiar with the code should work on it - you want to spread the knowledge around).

jb3689 5y ago

Working on hard problems isn’t always a rewarding path. I’ve seen plenty of very senior engineers get sucked into difficult problems with no additional resourcing only to be all but forgotten by the rest of the team. I agree that working on easy problems is not worth your time though

yobbo 5y ago

> and you let them fail a few times, and you wait until they come back with a readjusted attitude - that's evil. What, no? Letting ignorant people fall on their knives is /doing good/. It's the best way of learning. Letting ignorant people harm others - that's evil.

aliswe 5y ago

Am I the only one having a hard time understanding what he's saying? Somehow it just feels like a hodgepodge of words.