gregkerzhner (u/gregkerzhner)

gregkerzhner commented on Unbundling Airbnb peterfabor.com/posts/unbu... · Posted by u/peterfa

mijamo · 4 years ago

My experience is that the owners not usings agents are the cheap ones that will cause trouble for everything and not pay up for renovations and things breaking down. Hands off owners are the best as they just let the agent handle things professionally instead of trying to save a buck by calling illegal workers to half fix everything, then steal your deposit because things are broken when you leave. I have not met any of those magical owner that fixes everything correctly and would go the extra mile and I actually wonder what would be their inventive to do so, when simply having an agent take care of everything would save their time.

gregkerzhner · 4 years ago

I (hope) I’m like this. Im not handy at all, and have a tenant. When a problem arises for them, I just call the appropriate person (plumber, handyman, etc..) to come fix it. It’s the same thing I do when a problem arises in my own house. Problems don’t tend to come up too often, maybe once every few months, so I don’t see why I need to pay someone to handle this stuff for me.

gregkerzhner commented on Kotlin for JavaScript kotlinlang.org/docs/js-ov... · Posted by u/surrTurr

esprehn · 4 years ago

I'd be more interested if there was VSCode support. The JetBrains folks response was ridiculous and dismissive: https://discuss.kotlinlang.org/t/official-support-for-visual...

Apparently they refuse to support the most popular web IDE because Kotlin for JS is really about selling IDEA licenses. Fair enough, but it means I don't suggest Kotlin for anything except as a Java alternative and Android.

There's better options from companies that are less adversarial to their community.

gregkerzhner · 4 years ago

Seems like a no brainer - who wouldn’t want to use an awesome language like Kotlin and have it shared across iOS, Android and Frontend?

However, the actual experience is full of sharp corners. Get ready for nonexistent documentation, hacky plugins, poor debugging support, lack of proper native libraries and head spinning errors.

In general, it feels like doing carpentry using your plumber’s tools.

gregkerzhner commented on Be good to your mentors commoncog.com/blog/be-goo... · Posted by u/jger15

ChrisMarshallNY · 4 years ago

> which depends on them knowing it's there!

This.

Indexing is So. Damn. Important.

Documentation and knowledge discovery is crucial, and still very much a WIP.

I don't claim to have the answer. I write a lot of really relevant, heavy-duty documentation, with my projects.

That no one reads.

I know this, because they keep asking me questions that are in the docs.

I am their index.

gregkerzhner · 4 years ago

The problem with docs is that unlike code, documentation has no mechanism to keep it updated as things change. Even something really close to the code like code comments tend to get stale. Separate docs are hopeless - unless you are the owner of the code and the doc, and have great discipline, docs are almost guaranteed to diverge from the code.

When this happens, it’s tough to say what’s worse - a stale, and sometimes wrong document, or no document at all. So, in my career I’ve come to rely less and less on docs, and more and more on just reading the code. Docs can lie - code rarely does.

gregkerzhner commented on Pair Programming Antipatterns tuple.app/pair-programmin... · Posted by u/_ttg

whynotminot · 4 years ago

> That's fine, but it does not change the fact that many people struggle with it. Including people who manage to deal with "normal" communication just fine, but who find the intensity of a pairing unbearable. I can do it, but to me it is intensely uncomfortable to the point that as I've pointed out elsewhere I refuse to be pushed into it - for me it's not a problem, as my career has afforded me the luxury of picking and choosing positions where I get to decide what goes -, but I've met many brilliant developers over the years who just could not deal with situations like that at all.

I'm not disagreeing that some people don't find it enjoyable, and some people aren't good at it. Like anything else.

I don't see why you just wouldn't work at another company instead of demanding the company change its methodologies for you. I'd say the average dev shop leans more "lone wolf" anyway. Teams and especially companies that pair are the exception, not the norm. You're an experienced guy it seems like--I'm sure you've changed jobs many times in the past to find a culture and working conditions that suited you better.

> This dismissal of what to quite a few people is an inherent part of their neurological makeup as a "skill" comes across to me as incredibly offensive.

I'm sorry my view on this offensive to you. I don't mean to offend you, but simply stating you're offended doesn't change my perspective--I still view pair programming as a skill, and I don't think it's wrong to hire for skills.

gregkerzhner · 4 years ago

Ultimately, I file (mandatory, full time) pairing in the same category as mandatory in-office work, meant to encourage brilliance from random water cooler interactions.

In a perfect world, is a fully engaged in-office employee better than a remote one? I’d say probably yes. In the real world, is a disgruntled, commute tired employee better than a happy remote one? Unknown.

Same with paring. If your team is full of perfectly interchangeable humans drinking the same cool aid, then pairing sounds great. But real humans don’t work like that, and for every person who is boosted by pairing there may be another who is held back by it.

In the end, it’s likely best to allow employees to self select the mode of work which works best for them (location, pairing amount, computer choice) so that they are happy and productive. Any kind of top down mandatory policy on those choices will inevitably be worse than each person’s preferred choice.

gregkerzhner commented on Pair Programming Antipatterns tuple.app/pair-programmin... · Posted by u/_ttg

vidarh · 4 years ago

My experience is that pairing is deeply disruptive to my exploration of a design. It forces me to slow down and verbalise something that I can clearly visualise in my mind, when the fastest way to externalise it for me is often to write the code and show it. I'm happy to walk people through a prototype afterwards and discuss it and if necessary throw the thing away and start over or significant revise it. I'm not happy to have someone disrupt my thinking about a problem while I'm trying to focus.

Fundamentally I tend to think that people who insist pairing is ok to impose on people think everyone is like them, and don't see that it's forcing out people with different ways of thinking and processing problems. Ultimately I think it's bordering on discriminatory in that it's selecting for extroverts who don't burn out by the extensive amount of interpersonal contact pairing forces rather than selecting for results.

For my part I will never work somewhere that imposes pairing. I'd rather leave software development altogether than suffer through that, because it's not worth the exhaustion and the reduction in throughput other than occasionally (e.g. while training someone or walking people through a prototype). Thankfully I have the luxury of not having to take that shit.

gregkerzhner · 4 years ago

The crux of it is that pairing works for some but not for others. But often, it’s forced on everyone, usually from the top down. This is done in the name of vague benefits like “correctness” and “knowledge sharing”. Have these benifits even been confirmed through unbiased scientific studies?

The problem is that in the tech biz people tend to follow blindly without thinking. There was a point there where just because Pivotal Labs had some success pairing full time, everyone followed blindly. It’s the same with leetcode style interviews, open offices and ping pong tables - it worked for google and all of the sudden everyone is following blindly.

But personally, I wouldn’t work somewhere which paired heavily even if the benefits could be proved. I simply won’t do it because I don’t enjoy it!

Just like the choice to work remotely, the choice to not pair seems like a basic employee freedom that we should all have. Luckily, the way our industry is moving, such freedoms seem to be increasing.

gregkerzhner commented on Pair Programming Antipatterns tuple.app/pair-programmin... · Posted by u/_ttg

eikenberry · 4 years ago

> Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming.

I think this is the key takeaway with one missed point. IMO it definitely does produce more work vs. solo programming but that work is sub-par. The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and long term maintainability.

gregkerzhner · 4 years ago

The part of my brain which thinks deeply and produces elegant solutions simply shuts down when I constantly have to explain my thought process to someone else. I actually have the same problem in pair programming interviews - my brain tends to freeze up and comes up with strange, hacky workarounds at best.

Later, when I’m alone and can focus the proper answer usually comes to me. I know there are others like me who produce their best work when they can focus, alone.

If pairing works for you, then that’s great, but it needs to be consensual and optional.

The problem with pairing is that it tends to be championed and enforced by more social workers (especially managers), and forced on the less social ones, who are often not in a position to refuse.

gregkerzhner commented on Pair Programming Antipatterns tuple.app/pair-programmin... · Posted by u/_ttg

gregkerzhner · 4 years ago

Pairing is great for some tasks, like higher level design and whiteboarding sessions. But when it comes to implementation (coding) time I really dislike it.

I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work.

I definitely see the value in pairing for imbalanced situations (junior and senior, new engineer and tenured), but such sessions should have the goal of getting each person to operate independently, hopefully sooner than later.

Pairing just for the sake of pairing is an encroachment on many things I love about software (the ability to think about a problem deeply and quietly, the ability to work independently, the ability to check my Twitter feed as often as I damn please). I’m really glad the pairing fad seems to be dying down in general!

gregkerzhner commented on Times are great for programmers now. How does it end? vaghetti.dev/posts/times-... · Posted by u/vaghetti

lelanthran · 4 years ago

> We're still attending stand-ups every day with non programmers telling us when we can and cannot refactor. It's nuts to me that a skilled profession - that not many can do - lets themselves get micro-managed like this.

This is actually quite interesting as I was just talking to a few other professionals about this in a social setting. I was the only one in software development.

I mentioned how stand-ups work briefly, and that it might not be a bad idea to adopt for (for example) an accounting department to keep things on task.

The response was both extreme and universal: How the hell do you all accept being micromanaged to such a degree? Don't any of you have any dignity?

Every single one of them (all professionals, like I said) were adamant that they would leave any position that managed them no better than a burger-flipper.

No lawyer, accountant, doctor, engineer, scientist or other professional stands up each day to report *to their peers* on their progress.

gregkerzhner · 4 years ago

Daily standups can be useful when its a small group of people (3 or 4) working on the same project. In such meetings participants actually have the context to make meaningful suggestions based on other's updates "oh.. have you considered this? you should try this!"

Standups with more people working on separate projects are useless*.

My most recent standup with a group of 8 who were working on many separate projects spread across mobile, front-end and server. In this meeting, even if I did share some details about what I was doing, no-one else would have the context to help me. Also, it feels disrespectful to go into detail about something highly specific to my work while 6 other faces stare blankly as I waste their time. Ive heard stories from a friend's company of a standup with 30+ people across product, engineering and management. Could you imagine going into detail about your choice between an abstract class and interface on the call?

In such standups, the only sane action is to give a quick, high level update and mute yourself and go back to work. Standups like this should be ruthlessly dived down into several smaller meetings of people actually working together.

*Interestingly though, most people on my team love the standup for another reason - human interaction. Folks simply want to tune in and say hi to their team. In my opinion though, this isn't a good enough reason to keep unproductive standups, and the meeting would be better replaced with an optional 15 minute "coffee and chat" meeting. If folks want to tune in and chit chat, great - let them do it! But no need to waste people's time with mandatory "agile" ceremony.

gregkerzhner commented on Ask HN: How do you stay afloat in the subscription economy? · Posted by u/JadoJodo

gms7777 · 4 years ago

Never auto-renew by default.

Any time I sign up for something, I only sign up for a month and I immediately turn off auto-renew. If I miss it at the end of the month, I can sign up again, but usually I won't. If I get through another month, I'll consider a year if its a much better deal, but usually I won't.

The moment I see dark patterns in a subscription model (e.g., I lose my data if my subscription lapses, I have to phone in to cancel), I cancel and don't look back, even if I like the service otherwise.

gregkerzhner · 4 years ago

Same here. I subscribe and then immediately cancel, which stops the recurring billing but lets you use the service for the rest of the month.

gregkerzhner commented on Ask HN: What do you say to someone who wants to get into software development? · Posted by u/ramesh31

gregkerzhner · 4 years ago

Really, entering software isn't that bad. I didn't have any coding experience before college, and after my first year (which only entailed two software classes - I took a lot of humanities that year too), I had a job writing code for a research project. Thats a pretty quick path to employment - about 100 hours or less of training total*. I think any motivated person with a decent predisposition for math and logic could pick up the same skills in 6 months of effort, maybe even on nights and weekends.

I am not a super smart person either - I had an average talent and got average grades. However, the asset I do have is that I am OK with sucking and failing at something over and over again. I think this trait is more important than intellect.

Are you the kind of person that can bang their head against a problem for many days not quit? If so, you can be a software developer. Some natural intellect will help, but perseverance is likely more important. In fact, maybe being somewhat unintelligent is even better since you will be used to not succeeding at everything so easily.

*Caveat - it took me about 7 additional years to actually become good at writing code.