elmarschraml

Depends a lot on your situation:

Does "CTO" mean you are the tech lead of a small (single team) engineering organization? Then everything written for staff engineers applies. E.g I've heard good things about "Staff engineer's path" by Tanya Reilly.

Does "CTO" mean you are leading an org that is too large to be hands-on with tech, and need to build an effective structure and culture? Then I second the recommendation for "an elegant puzzle" by Will Larson.

Or does "CTO" mean that you switched from being an engineer to managing a team of engineers? Then everything for new managers applies, for starters I'd recommend "Becoming an effective software engineering manager" by James Stanier, or "Engineering management for the rest of us" by Sarah Drasner.

For some good general material, I'd also recommend the resources that Gergely Orosz makes available for subscribers to his "pragmatic engineer" newsletter. Those are templates for the kind of documents and processes you will most likely need - if you're new to the role, you will not go too wrong by using them, and if you want to create your own they are excellent starting points.

Devastating.

Ever since I met him as a young developer, when he was speaking at a local user group, I made it a point to catch any talk he gave at any conference I was at. He was one of the few people who combine huge competence and deep experience with being able to speak and communicate them really well.

Plus, he always came across as someone who was utterly professional, yet manages to stay human, accessible and deeply committed to their values - the kind of person I aspire to be.

Here is how that press release should have read:

First paragraph: Get to the point (layoffs are happening) immediately, and state the concrete reasons why they are necessary.

Second paragraph: Thank the people being laid off, call out some of their good work, and talk about the things you are doing to help them find a new job.

Third paragraph: Mention the steps you are taking to avoid having to have layoffs again. Be as specific as possible. When mentioning "focus", that means focusing on one, possibly two, very specific things.

Last paragraph: Motivation for the future. Renewed commitment to making Firefox better.

Skills are tactics. Dealing with a recession is about strategy.

Most importantly: this is a time to focus on reducing risks, rather than maximizing profit.

This is a crappy time to start a startup or being a freelancer. Keep your job, build your skills, save money, and start in a few years.

Think about your job's security: Pay attention to your employers annual/quarterly reports. Which industries does your employer sell to? Travel, restaurants, hotel, retail, small businesses will be the worst hit, with little money to spend.

This is also a bad time to change jobs - depending on your local laws, it probably is much, much easier to lay off someone who just started.

Maybe broaden your skillls. In good times, it is more profitable to be a specialist - e.g. much better to be THE leading expert on scaling wordpress, rather than an all-purpose linux admin. In bad times, when jobs are scarce, being less of a specialist increaes the number of jobs you are suitable for.

Save money, lower your burn-rate, extend your runway - usually meant for start-ups, but this goes for your personal finances just as well

Become familiar with laws and benefits from the government for unemployment, lay-offs etc - if you should happen to find yourself unemployed, know what you have to do, how much assistance you can expect.

That being said: If you have a high risk-tolerance, and can afford to, now is also a great time to start a business or to invest, simply because nobody else is, so there is much less competition for everything.

Having them do a code review (about 10-15 minutes), i.e. have a short (about 50-80 lines) piece of real code, that I have prepared with plenty of problem, messes, non-idiomatic code, or little ugly things.

NOT a test as in "find the 10 hidden mistakes", but an invitation to talk about ways to improve the code. I make it clear to the candidate that it's not about the syntax, or any algorithm, but about quality.

It's really good to see what kinds of things they care about (e.g. do they look into low-level performance, or more into things like variable naming and method length), how deep their knowledge of the language is (e.g. do they recognize non-idiomatic code, and suggest more modern approaches), if they are more of a high-level thinker or more detail-oriented etc. And of course, it nicely weeds out the (surprisingly high) number of people who cannot really program, without relying on any memorization of keywords. Plus, it's pretty realistic - nobody ever writes code on a whiteboard, but doing code reviews of code somebody else wrote is something that happens all the time.

Most candidates find that task quite fun - and with really good candidates I quite frequently learn something new myself.

I was planning to do a blog post about why and how I do that review - let me know if that would be of interest to you.

Generally, asking opinions rather than specific technical answers.

Asking "Do you have experience with technology X" is useless - everybody knows that "yes" is the expected answer.

Asking specific technical questions is random - they might or might not have come across that particular problem. Also, in practice the answer would simply be looked up, and you don't want to hire for memorization.

Instead, ask things like"How did you find working with <technology X>? Can you compare it to <common alternative>, or <similar tech also listed on their resume>?". Or maybe "what worked really well with <technology X>? What pitfalls did you fall into? Anything for which you would, or would not, recommed it?"

This kind of info is hard to fake, gives you good insight into their thought process and priorities, or just gets people talking about their projects more easily than a generic "tell me about your work on project y".

- Savings: a few months' living expenses in a readily available cash account. What happens when you suddenly finding yourself having to pay a few hundred or thousand bucks for an emergency? Not having savings means "Panic mode / scrimp and save / have to get credit". Having savings means "a number in my back statement changes, but does not really affect me"

- Access to experts: anything from doctors to lawyers or accountants to a bike mechanic or plumber. When you're faced with a hard problem, it's really comforting to know that you can get expert help rather than having to meddle through yourself.

- Time: Could be hiring a cleaning lady, so you don't have to spend time on your weekend cleaning your house. Or daycare for the kids, so you can get a break from watching the kids and do grown-up things for a while. Or just taking an extended unpaid vacation to unwind for a bit.

Unrelated to the site, but about the patents: How can a specific games console, like the Nintendo 64, be patented?

The name of the product, and maybe some brand-specific design elements, is a registered brand, sure. But a patent is for an invention, and it's not like a specific games console is a new invention - just a variant on the existing invention "games console"?

The 4 classic mistakes of programmers in their first "real" job (all made by myself, too, of course):

1) Spending a lot of time building something yourself, where you could have just used an existing library. Example: Writing XML parsing code using the plain DOM in every single DTO class, rather than using a mapper library.

2) Starting a huge refactoring or rewrite of existing code, for no other reason than you think you know better, while being too new to the project to realize where the real problems or reasons lie.

3) Over-engineering. Typically in building a flexible, powerful framework, where a simple hardcoded implementation would have been sufficient. Example: PO asks for a page with statistics about how often X has happened per month. Built a framework for displaying any kind of statistics simply by supplying a where-clause. Was never used for anything but the original request.

4) Giving unrealistic time estimates by assuming the best case for everything. For any kind of complexity in the requirements, there's always something that does not work out as expected, so plan for it. Also, in most cases it's better to give an estimate that is a little longer, but realistically and reliably achievable.

Listening to podcasts. Perfect for when both your eyes and hands are occoupied, but your brain is bored.

To put in in less nerdy terms, cleaning, ironing and other housework, exercise and walking will never be boring again.

Dreamweaver is (or was, back in the day) a good implementation of a category of software that does not really exist any more.

Back when the web stated, creating a web page meant mostly writing html, with a bit of graphics and scripting thrown in. The idea was that by using Dreamweaver, regular people (i.e. not expensive software developers) could do the layout and formatting of web pages. And it worked pretty well for that.

But it turned out that "creating html from text and image content" is not a job any more that needs specialized software.

On one side of the spectrum, web developers do not create static html any more, but full-blown web applications where html is just the output. If you are using e.g. a js templating framework, a visual tool like Dreamweaver wont help you very much.

On the other side, if you're a business user putting text on web pages, you are probably not creating html pages, but entering the text in the web interface of e.g. a CMS system.

The headphone port is inherently analog - more like power than VGA.

With VGA, it made sense to switch to digital ports once the displays went all digital (flatscreens). With VGA, you were converting a digital signal to an analog signal just to send it over the wire, where it got converted back to digital to drive the display.

But speakers or headphones are analog devices, they need analog voltage to make membranes move back and forth. The analog headphone port directly drives the speakers, whereas any digital port needs a chip inside the speakers to convert the digital signal to analog. It makes much more sense to have a single DAC (digital-to-analog converter, or "soundcard") inside the phone, than to have a separate one in every single pair of headphones.

Granted, you could argue that a digital signal travels better over the wire, or that the user could choose to use headphones with better quality DACs. But for all practical purposes, the analog headphone port works fine, and when it comes to standards, open and universal wins over the highest quality any time.