65 karma · joined August 7, 2019
Taken from the product site (not this blog post) that was linked by another user. So you get to choose it would seem.
Isn’t that the entire thing the article argues? That journalism (real journalism, that is meant to keep those in power on the straight and narrow), suffers because not enough money goes to the actual journalists? Stock is the public’s perception of something’s value, but the actual value to society can not be measured in stocks.
That being said, 6 months is a perfectly reasonable time for an employment that you’ve found unreasonable. If I’d see something like that on a resume when I was hiring, I might ask a question about the short stay during the interview process, but an answer about mis-matched culture fit would be perfectly legit for me.
He went on to make Typescript - making sure that JS has types, so when making method calls you could have the compiler tell you when you did something wrong. Again, errors/exceptions did not get a throw clause, making it impossible to model the error state that the language provides. You can describe, in detail, the data for successful run, but are unable to describe the data for any error state. If the goal was to make the system more sound, I have a hard time seeing why the error state is not taken into account.
A lot of the described (and for myself experienced) cases against checked exceptions comes from external libraries or the language itself. IOException has a special place in hell, but for my own business logic (or inherited legacy code) in an application that spans thousands of files and classes, I would very much like to describe and be made aware of the error state throughout my application.
In Java, if I introduce a new business logic error state, all the places in my http (or cli or whatever) layer that uses that business logic will get highlighted for me, and I can then map it accordingly. In C#, that is not the case. If I don’t want checked exceptions, I can always catch it and throw a runtime exception - but I have the option. As a developer who likes to think I know what I’m doing, I would at least like the option. In C#, that decision was never mine.
With TS, we have a system that lives around being configurable. One day, I would really like to see this being up to the developer and a parameter in the tsconfig file, maybe with a configurable list of error types to be considered RuntimeExceptions. That way, if I don’t agree with a library’s use of the feature, I can tell TS to not report them by considering them Runtime.
Might just be because I use an architecture that actually favors CheckedExceptions, but not being able to describe the error states of my business logic really grinds my gears ;)
Either way, there isn’t much you can do if the burnout is real, other than being honest. Explain why you’re feeling burned out, perhaps even come up with suggestions to how it potentially could be mitigated. A good manager will try to accommodate you in some way. If they’ve been with the company for a long time, they might even have experience with dealing with burned out staff or have the option to shuffle some tasks around to give a tiny bit of variety. If he can’t and just lets you go, then the deadline just moved - if you were burning out, it would eventually have come to this anyway. Hard to hear, harder to experience but nothing to do but look for something new with more meat on it :)
I also lecture them at the end of a call sometimes. One of the more recent calls, they recruiter was looking for someone to fill “an architect position”. I asked him if he knew anything about software, and he conceded that he didn’t and that he was a psych major. I asked him if the people who told him to find an architect had told him what that entailed. They hadn’t. So I broke down three different types of architects there is in software development (code, systems and enterprise) told him he was most likely looking for a systems and what profile they could have and had a general good discussion with him. When I’m done at my current position, I have a good repor with this guys to have him find me an interesting position :)
So advice to recruiters:
1) Know what you have to offer
2) Know what you are actually looking for, even if it’s complicated. If you want to hire experienced people, seem like you know what you are talking about.
3) Proof read you written communication. You main job is to communicate and make a good first impression, but if your outreach mail/message is filled with spelling mistakes or contradictions, I’m not gonna respond.
4) Don’t try to sell me the cat in the hat. With experience come the ability to look right through your babble. If you want people like that, be open and honest. We might cut you some slack if the position is interesting enough to us ;)