Sketch is a great app. It's a shame that it's Mac native, I had to stop using it when they killed off support for High Sierra.
I wouldn't be proud of building on an increasingly user and developer hostile platform, but thats just me.
> For us, the ultimate benefit of being a native macOS app is that it puts the choice in your hands.
That's... kind of a weird opinion but all the power to you. I have never felt like "choice" was a core value of Sketch, since it doesn't give me the choice to run on my hardware or software versions. But thanks for letting me own my own data.
Because it's slow and difficult to use compared to sketch. Plus I need my files on my drive 100% of the time and routinely work without reliable network access.
I get kind of why Figma is popular, it solves issues with sharing and collaboration. But the day to day usage is crippled by the fact it's in a browser and not a standalone app where I need it to have total control over keybindings and shortcuts for my workflow. Meanwhile in the browser, hijacking that behavior is a UX antipattern.
Sketch is just so much less cumbersome than Figma it's not even funny. It's easier to use than illustrator and Xd too.
Is there any healthy place or way or method "juniors" can learn through experience without being screwed over? Be it low money, blood money, poor experience, terrible managers ... is "let the vile companies get the fresh graduates" the best answer here? What can be the alternative here?
[Edit:] Not everywhere has mentors. In my experience, mentors are a luxury. Saying "but mentors" isn't an end-all True answer. Same thing for Internships -- not all College Universities require them.
Maybe I am in a personal moral or ethical crisis here, but at the moment I'd like to stand by this line of question.
>Is there any healthy place or way or method "juniors" can learn through experience without being screwed over?
That's a great question. I agree that mentors aren't the catch-all answer. I will say, though, having been on both sides of the mentorship divide, that a good mentor is a powerful positive force in your career. Doesn't change the fact that it only gets you so far.
When it comes to money, I'm afraid there isn't a whole lot junior technical candidates can do to get more. In my experience, technical experience and negotiating leverage are the two surest paths to getting paid more. Junior engineers straight out of college have neither of these things. Jobs beget negotiating leverage. If you have a job, a new job has to give you a better deal to convince you to leap. That's something that a fresh college graduate, inconveniently, lacks.
There seems to be a lot of advice here that suggests taking the best job you can straight out of school, and then switching jobs as soon as you reasonably can. That's what I did - I spent a year at a big chip company, decided it wasn't for me, and left for a consumer electronics company. That one year of credible work experience netted me a ~30% raise on switching.
I don't think it's as big a problem, first because everyone will have bad experiences at some point and that's a growth opportunity in and of itself. Secondly because good candidates are apprehensive about bad companies regardless of their experience level.
And frankly the market is competitive enough that you can always quit a bad job to find a better one, if you're qualified.
> everyone will have bad experiences at some point and that's a growth opportunity in and of itself.
That's a really great point to bring up. Lousy professional experiences are opportunities to learn, or grow. Doesn't make them fun, but it does make them valuable.
>good candidates are apprehensive about bad companies regardless of their experience level.
I'm not certain this is true. There are plenty of smart, motivated people who don't necessarily have the career experience to notice red flags at a potentially negative employer.
If there's a lesson from the ongoing collapse of GE, it should be "stay the fuck out of finance."
There's an interesting take that's opposite here which I don't see mentioned, which is that software businesses make absurd margins and right now the best place to put that money is in the pocket of their employees or new employees (or overseas, or in buybacks). That money could be put to use to increase their margins through financial services but personally I don't want to be a part of that.
They're great for implementing complex language semantics like cooperative multitasking (using macros to expand yield/resume points into a state machine for stackless coroutines, for example). Or cool object systems like type classes and multi methods.
Smaller stuff like hand rolled parsers and serializers are much easier to get working fast (both time to write and time to run) using macros. Since a good chunk of my work is data flow in one form or another, I miss LISP macros a lot.
Weird not to mention acoustics. Temples, churches and venues (opera halls, in particular) needed high ceilings to carry sound before electronic amplification.
I have lived in a home with high ceilings. I find them gaudy and poor design features, unless you live alone. If you have high ceilings, particularly in open floor plans, everyone is going to hear everything all the time. Doubly true if the stair case opens up to a wide space instead of being closed off.
Effort and business utility are not necessarily linear. For argument's sake let's assume they are. A manager affects the productivity of all of his/her reports. Let's say a manager has 10 reports. If the manager stops working twice as hard, maybe all of the manager's reports would become 1/2 as productive. That means the manager's 2x work provides the same business utility as 5 ICs.
Lots of people in a business aren't submitting code, but that's not really my point. Depending on a manager's style they can increase synchronization overhead between team members and different teams to the point that everyone's productivity is reduced while the manager has never been busier or productive on paper.
A manager's productivity IS the team's productivity, and should be measured in results.
A "productive" manager that slows down the team isn't an effective manager at all, no matter how hard he or she is working.
The manager might be able to scapegoat a poor team member or two when poor results become evident, but sooner or later, he or she will have to pay the piper.