Appreciate the effort the article author put in, but I'll be contrarian here (in the hopes of saving people time) and say that I think this is the wrong approach to take to getting hired (the effort:hire ratio is terrible).
I don't know why, whether it's to be fair or avoid litigation, but in most companies I've worked for or interviewed with, the senior engineers, hiring managers, HR, etc. don't have as much influence over the hiring process as you think. You'll probably still need to go through 5 stages of interviews, including a white-boarding or a take home test. Otherwise you wouldn't have all these "rockstar" programmers on Twitter complaining about the interview process. The best that these "influencers" can do for you, is to tip you off to an opening and maybe help towards the end of the interview process.
The other issue is, how do you know you're betting on the right horse? e.g. is the person that you're getting cozy with really going to help you career? You only have so much time and "connections" to invest.
My advice: instead of going to meet ups, take more interviews and improve your interviewing skills. Instead of spending 2-5 hours/week going to meet ups, take 1 interview instead. Even with no preperation, you'll start to see the pattern in the types of questions people ask. Improve on your answers. Interview again.
The problem the author of the article is writing about is being so shy that you'll never be able to benefit from "practise" interviews. You should really consider whether or not you understand the problem before you attempt to solve it.
This is a big problem with hiring. So many people think hiring is a simple problem that has a simple solution, but you're dealing with humans. There's so much variety in the way people think and act that there won't be a generalized solution. For some, networking outside of interviews so you can get a recommendation is a valid approach.
I think you're confusing what works in theory vs the current state of affairs. At many companies if you speak of "you're dealing with humans" and "way people think and act" in a hiring process you're automatically inviting interpretations that can be used to justify the reason you didn't hire someone was because of discrimination. Simple as that.
If you really want to see change in the world stop preaching truth to believers, but instead root cause the problem and find solutions that address them. In this case, legislation.
What you're saying is definitely true for the more mature companies (say, 1000+ employees).
I curious if the author has experience with this working for startups and their ilk, which may not have become large enough to have a proper recruiting division.
The challenge networking potentially solves is getting a recruiter to pay attention to your resume, but from that point on your resume has to be impressive looking enough to get you to the interview room. And unfortunately I know (and helped) a lot of engineers who've done impressive work but didn't know how to put that on paper effectively.
I’ve hired at multiple smaller startups, and the rule has always been that if someone gets referred by an existing member of staff then the referrer isn’t involved in the interview process beyond being a high confidence reference check.
Networking gets you to be exposed to opportunities at those companies, maybe some tips to prepare for something specific for that company. But it is not going to take away hard work that needs to be done.
Agreed. The advice in the article would work if it was about anything, but getting a job. The skills mentioned could be immensely helpful in building a network of people ("allies"?) for the purpose of getting customers for your startup, meeting other founders and even meeting angels and VCs to fund raise.
Please don't use it to get a job. There are objective criteria that companies would like to think they're using to hire the most qualified candidate (reality is probably very different). That's the best way to assure you don't hire non-performers and avoid the huge liability associated with choosing an arbitrary hiring process in many states.
Even at a big company, having someone pushing for you internally makes a difference. Probably not much on the hiring process, but pushing bureaucracy, ensuring a recruiter / coordinator looks at your CV and schedules your interviewers sooner, and so on.
I actually think it's more useful for a different reason: finding out who's doing interesting stuff, knowing where it's worthwhile applying.
SailfishOS is officially supported on a number of different Sony mobiles (e.g. X, XA2 range, 10 and 10 II ranges). All these devices continue to receive updates.
SailfishOS is not completely FLOSS, but it's real Linux, and it's polished enough to be a daily driver (I've been using it for 7 years).
I daily drove an N9 when it was current hardware, and it was reasonably good. Harmattan was buggy as hell, but it held promise.
However, I found it extremely disappointing that they didn't cater to the FOSS community by making it easy to reproduce and iterate on the OS. If Nokia with the N9 took an approach to the OS and community akin to what Pine64 has been doing with the Pinephone, we would be in a very different place today with Linux phones.
Pine64 doesn't do any software, so the comparison is apples to oranges :-)
The software from the N9 became what today is SailfishOS (mostly FOSS, but UI closed), and for something fully FOSS, Nemo is also derived from Harmattan, https://nemomobile.net/
> Pine64 doesn't do any software, so the comparison is apples to oranges :-)
True, but Pine64 facilitates the FOSS community in spades when it comes to shipping a hardware profile with mainline support, and ensuring it's trivial for Pinephone users to run alternative operating systems down to the boot loader.
I'm a developer and the N9 was completely opaque, it would have required spending significant time just to even begin figuring out how to replace the OS.
I'm now into my third year with Sailfish as my daily driver (Sony Xperia XA2 Plus) and can confirm it's first rate. And if you need an app that doesn't have a native Sailfish version, it'll almost certainly run the Android equivalent.
Wow it looks great, I had no idea it existed in a usable state. I though it was just the bones of Meego, I used Moblin on an N800, it was great sat the tine, it looks like a truly functional experience.
Wow, very sad. I remember listening to Accordion[1] for the first time and thinking it sounded like no hiphop I'd heard before (no chorus, really unconventional song structure, dense lyrics, an accordion providing the hook). That was the gateway to the rest of DOOM's discography for me.
In my opinion the shift from desktop to mobile across the wider industry took the wind out of Gnome's sails (and desktops in general, no matter the platform). It feels like there's been very little (visible) progress made on any desktop in the last 10 years.
The problem is Gnome seemed to look at mobile and "pre-sabotage" itself. Both Gnome 3 and Unbuntu Unity wound-up creating "tablet/mobile ready" shells when no one was going to be using them that way. Tablets only seemed to be the wave of the future because they were new and everyone was buying them. It only became evident later that laptops were going stick around for a while and be what most people still used if they were doing "real work".
But with the narrative being "this is the future", they were more or less pressured into it. The designers as well as programmers are volunteers and I would imagine designers want to work on the "cutting edge" even if that cutting edge is a complete disaster for users (just Microsoft's redesigned UI was).
Their target wasn't just tablets, but any device with a touchscreen and/or a small screen. As a Netbook user, I loved Unity and was excited about the Gnome 3 shell. It seemed like the logical progression of Ubuntu Netbook Remix.
What changed is that display and battery technology got better. I went from carrying around a tiny PC with an undersized keyboard (remember the Eee PC?) to one that weighs less, has a full size keyboard, and sports a display larger than the one the came with my first desktop computer. On this hardware, a traditional desktop environment feels cozy, while Gnome Shell feels foreign.
I owned one of the later models of the Asus EeePC and let me tell you, Gnome 3 ran like a old dog on it. Totally unusable. I don't know how you could use it. The processor was awful, the screen resolution tiny, while Gnome was a CPU hog and wasted screen space the eeepc simply didn't have with spacial bloat of interfaces evidently designed to be fat fingered on touch screens the eeepc didn't have.
That, plus the shift to SAAS apps so that everything runs in a web browser. Basically, the two things I have open most of the time are Firefox and a bunch of terminal windows.
I think the shift to web apps and repackaged web apps happened largely because of how insanely hard it is to roll a decent multiplatform app between mac, windows and the various linux platforms even before considering mobile. For example, the OGL backend for GTK3 has been broken on MacOS for years and while there's been a rewrite for GTK4, porting from 3 to 4 is non trivial and so is maintaining 3+4 so GG if you're a small project.
True enough, but Gnome has the advantage of being the basis of Phosh + being able to share applications with it, as per on Pinephone and Librem 5.
It works as a converged desktop too. Windows can't do that, OSX is only just getting there. It is impressive that an open source project is so ready for it, really.
The problem with GNOME as the basis of Phosh is that little work has been done to optimize GNOME for low-memory, low-CPU-power environments. The Pinephone has limited memory (especially the first board with only 2GB of RAM) and an ancient, low-end processor, and while it will run all this GNOME stuff, it does so only at a snail’s pace. On the Pinephone takes several seconds just to open the wi-fi settings to activate or deactivate wi-fi, for example, something that most mobile-phone users today expect to be a near-instant thing, because on Android it is just a quick swipe and tap.
I’m not talking about the Phosh executable as much as all the other things that Phosh on Mobian is meant to provide an interface with: so much of those preinstalled applications and libs in Mobian are derived from the GNOME project, and they just haven’t been optimized enough to run well on the PinePhone’s hardware.
Oh I see, misunderstood you there. Yeah, many apps are basically just the desktop version with some pre-configured scaling to make them barely usable - but as far as I know it is only by necessity until the mobile friendlier alternative emerges.
But while it is good to see the advances mobile linux GUIs make, they are still far from usable as a primary device :/
A simple one, that perhaps doesn't scale (unless you open multiple gyms) is to provide a boxing/MMA/BJJ gym with good coaches.
It's so cliche, but giving teens a physical outlet, where they can begin to understand that consistency leads to results, can sweat together, socialise and build comradery and true confidence will go a long way.
It's simple, and you might only be helping a few teens a year, but it's a good start. I've seen it transform some troubled kids (and grown ups) over the years (drug addicts, and extreme anti-social cases).
This is why I use SailfishOS. Modern Android and iOS are so insanely complex, it seems impossible to do the simplest things with code. Yes you can root your phone, and you have access to (Android) source code including 3rd party FOSS apps and build tools. However, writing code, building, and iterating on the device is almost non-existent (I don't consider termux an ideal fit), not to mention the sandboxing/protections that are in place.
The hacker spirit still seems very much alive in the SailfishOS community. The community isn't big, but people come up with smart ideas that leverage existing solutions. SSH in, write Python code, write QML, zypp install build tools, pip install libraries (inside virtualenv), execute it, see changes on screen, hook into the existing system using xdg standards and dbus, manage services with systemd. It's fun to hack on.
If I had to characterise it, Android/iOS vs SailfishOS, is the equivalent to Java vs Python. The former is well-engineered, secure, perhaps overly architected, and widely used for "serious" and Enterprise solutions. It certainly has good reasons for how it does things. The latter is more organic; the same solutions can be achieved (with certain caveats) but with less hassle.
From a developer perspective, Android and iOS have sucked all the fun and creativity out of the devices.
* Sorry about piggybacking off top post, I just found that it strongly resonated what I've thought.
What device are you running SailfishOS on? I'm considering switching to a FOSS-based OS on an Android device at some point but I'm concerned about specs being poor and lack of availability of apps (living off FDroid's repos wouldn't be enough for me).
I use the Xperia X. Newer phones are supported (e.g. XA2), and I'm speculating here, but I imagine even newer phones are in the pipeline (e.g. Xperia 10 II).
I don't recommend SailfishOS to anyone who is looking for the fastest/most supported device out there. I recommend SailfishOS devices to those who primarily use their phone as a phone (and a desktop/laptop as their primary work station), and want an independent mobile device, or want the Linux ethos on their phone.
That's only part of the solution. Energy generation makes up ~25% of emissions, agriculture, manufacturing, transport, etc. make up the other 75%. All of these will increase as the 3rd world industrialises.
Two questions:
1. Do you plan to monetize it to aid in the sustainability of this product?
2. Any thoughts on implementing this functionality for playlists?
1. Yes I'm planning on releasing Songwhip Pro (https://songwhip.com/pro) which will be a customizable version of the free product targeted at artists, labels and marketers. It'll allow an artist name to be 'claimed' unlocking write access and pro-only features.
2. I don't have the bandwidth to take on playlist functionality at this time. I'm trying to focus the offering and really nail the original problem before taking on new challenges. I've seen competitors try to spread themselves too thin and end up not doing anything exceptionally.
I was originally interested in this, but I recently found a seemingly good alternative in the Color Maximite 2 (http://geoffg.net/maximite.html) which sits somewhere between 8bit (feel) and 16bit (graphics).
You can get a similar feel, very inexpensively, with an ESP32. Tiny Basic[1] and the FabGL vga library[2] turn an ESP32 into a reasonable retro clone. You can even find an ESP32 that already has PS/2 and VGA connectors for $11[3].
I think that for such modern retro style systems is very important to have a huge community and because of this a legacy compatible systems like ZX Spectrum Next[1] or MEGA65[2] or systems designed from persons with a huge audience like David Murray[3] are clear winners.
ESP32, TinyBasic and FabGL look cool, but it seems that there is not enough people knowing about them and wanting to develop software for/with them. Unfortunately the same can also be said for the Maximite series of machines. I wasn't able to find any dedicated FabGL or Maximite community sites.
The same cannot be said for the upper mentioned computers which apparently already have significant community and some people actively developing games and other software for them. ZX Spectrum Next even have a dedicated distribution site[4]. Commander X16's official site has community downloads section[5] which looks similar.
If someone wants only to have some fun programming a retro like machine in Basic or in C++ with FabGL, ESP32 is really a cheep alternative, but most probably what he does with it, will stay only his own personal experience and he will not have a huge chance to find some audience or community.
Something I found frustrating - the Maximite repl goes out of its way to prevent the user from writing machine code. This is not in the spirit of classic systems.
Maximite lacks memory protection, and does allow direct writes to memory. There will be a way to over-write a basic function in order to hijack initiative into machine code.
I was going to post a similar thing. I know the 8 bit guy reviewed it positively, and for me the CM2 is a better bet as it can run BASIC code about as fast as a 6505 can run assembler.
I know it's not as legitimately retro (in terms of chips), but that doesn't matter to me; what does matter is having an accessible system to play about with and hopefully show my son that programming can be fun and he can make games without an impossibly step learning curve (ie how I felt about my ZX spectrum back in the day).
I hope it works out. I was excited to get my kids interested in programming like I was in the early 80s. What I discovered was some combo of my kids are their own people and not my clones, but I think more importantly, the bar for computer magic has risen. When I was 8-12 just making a computer do anything was magic. Computers were mysterious and still a bit rare. Today my kids are growing up in a world of total computer saturation from phones to pads to laptops to the cloud. Much as I wished programming would capture fire for them like it did for me, there is no magic for them in making the computer do a few simple things. The world still sort of awaits the next paradigm to spark the next generation of inventors and creators.
Yep I briefly had my 10 year old snagged on Pico-8 last week -- he immediately and intuitively seemed to understand what was going on as we kind of pair programmed together -- until I left the room. Then he just started playing other people's Pico-8 games and described the whole thing as boring.
He's got potential as a programmer. Maybe someday someone will pay him to do it. But you're right, computers now can do everything so easily, there's no glory in doing simple things for the sake of it.
First, wow! I didn't know about the Pico-8. Seems fun! I like that its limitations can foster creativity.
Second, maybe your son needs more time. Back when I was a kid, I played a bit with BASIC on my C64 but it was very frustrating and I gave up trying to do something complex, and ended up just playing games, much to my parents' chagrin.
> I know it's not as legitimately retro (in terms of chips), but .. what does matter is having an accessible system to play about with ... (ie how I felt about my ZX spectrum back in the day).
Hopefully we'll see more focus on RISC-V chips in the future. A RISC-V based, maximite-like system would bring assembly-level programming that's as simple and accessible as it could feasibly be, and quite comparable to the ease of writing assembly for the old 8-bit chips.
I had started on a project like this, which I was calling "Retro V" (retro 5... is alive! for the 80s movie reference...)
It's a PicoRV32 core + a simple 'retro' style video display processor (sprites, character generator, and 640x480 8 bit palette indexed bitmap graphics) that outputs on HDMI/DVI, plus 512KB of SRAM that runs on the CMod A35t board (Artix 7 35t FPGA + SRAM on DIP friendly package), which I intended on making a simple daughterboard for (to hook up PS/2 keyboard & mouse, add some extra RAM etc.)
The "OS" was to be mid-80s style -- boot to a REPL, either a BASIC or something like Lua, with simple DOS commands and an assembly language monitor.
I got pretty far but stalled out around Christmas when things got a bit busy personally for me, and I ran into the complications of getting the QSPI flash chip interfaced for storing programs.
I might pick this project back up again. I think it has potential.
BTW I don't actually think RISC-V assembly is all that great for beginners. It's a bit awkward to write directly. For example, to set a 32-bit register with an immediate value requires setting the upper 20 bits followed by the lower 12. Similar with PC jumps, etc.
In general RISC architecture assembly language is meant to be written by C compilers, not humans.
I actually think beginners might be better off with a CISC instruction set (like the 68k or similar).
EDIT: Thinking more about this, out of all the architectures that GCC currently supports, 68k seems to be the most "retro" and easiest/most enjoyable to write by hand.
Any project that will only be programmed in BASIC, C or something will make the processor it uses irrelevant. Only if there is some assembly will the processor matter.
One fun pseudo-retro project would be an incremental BASIC compiler which allows simple inline assembly. That is: any given line can be either a BASIC statement or an assembly instruction. The "incremental" part would be that every time a new line is entered the program is patched to include it. The program would be stored in machine language with two helper tables: line number to address mapping and variable name to address mapping. When you LIST it would decompile each line as it goes to the screen (easy to do since the compiler wouldn't have any optimizations). BASIC already has to include a garbage collector to deal with strings so this would not add too much complexity.
I agree that the 68000 is nicer to program in assembly than the RISC-V. I started a simple RISC (only a short presentation so far) with the goal of having nice assembly code: https://github.com/jeceljr/baby42
> It's a bit awkward to write directly. For example, to set a 32-bit register with an immediate value requires setting the upper 20 bits followed by the lower 12. Similar with PC jumps, etc.
Yes, IIRC the standard description of the RISC-V ISA includes assembly macro-instructions that can be programmatically expanded into sequences for things like those. Similar to how "mov" is actually implemented as a special case of "add immediate".
Oh for sure, that's great for writing, but when disasembling or looking at the asm listing for a C program you don't get that. Which happens a lot while working on a low level machine like this, especially when building it :-)
Why not just boot up the vice emulator and give them a true c64 experience? The CM is a neat project but if you're going for retro seems the worst of both worlds: modern, under-utilized hardware with artificial limitations. To me the later is the goal to force creativity; the hardware in this case seems superfluous.
Because previously we've spent a bit of time using an arduino to do something, and he enjoyed learning to solder and connect LEDs up. So I think that the experience of building the computer will have him more invested in it.
If you want a modern BASIC experience, Risc OS Pico on a RasPi Zero is a very good one.
1GB flat memory space, a blindingly-fast 32-bit structured BASIC with local variables, named procedures, IF...THEN...ELSE and DO loops and so on, and it supports inline ARM assembly. You can enter ARM assembly language directly into your BASIC listing in the same editor, and it will be assembled and run when you type RUN.
The main pusher behind Commander X16 talked a bit about this alternative. It does feel like an 8-bit machine but IMO is closer to an emulator than 8-bit hardware. It's super overpowered compared to what it represents with the most intriguing aspect being it runs reegular old basic faster than a C64 runs machine code. Some of the creations are pretty amazing, but mostly because of today's hardware. It's also been pretty difficult to get a maximite (though this might clear up)
He reviewed the other computers in the Maximite series in the past. He considered the Maximites as possible candidates for what he was looking for in a "modern" retro style computer, but decided to pass on them as they weren't quite what he wanted.
Very interesting machines nevertheless, and fun to play with for retro fans.
I'll add my two cents. I use emacs for email (mu4e+mbsync) and having used Thunderbird, Claws, Gmail, Roundcube (probably many others), emacs is, without a doubt (for me) the fastest way to launch/read/search/reply emails.
I can launch an emacs email client in 1/10th of a second, and it takes me straight to my inbox which is setup to highlight the emails I'm interested in. Opening an email to read is again 1/10th second (thanks to mbsync). Finally search via mu4e/xapian is blindingly fast (faster than gmail). For me, the competitors aren't even close.
Genuinely curious what your life is like such that an email app that takes longer than 1/10th of a second is just beyond the pale? Are you really that time poor?
It's really nice to have fast response clients. .1 or .3 seconds doesn't matter in the sense of saving 1000 seconds a day probably, but immediate response from tools is useful.
I don't know why, whether it's to be fair or avoid litigation, but in most companies I've worked for or interviewed with, the senior engineers, hiring managers, HR, etc. don't have as much influence over the hiring process as you think. You'll probably still need to go through 5 stages of interviews, including a white-boarding or a take home test. Otherwise you wouldn't have all these "rockstar" programmers on Twitter complaining about the interview process. The best that these "influencers" can do for you, is to tip you off to an opening and maybe help towards the end of the interview process.
The other issue is, how do you know you're betting on the right horse? e.g. is the person that you're getting cozy with really going to help you career? You only have so much time and "connections" to invest.
My advice: instead of going to meet ups, take more interviews and improve your interviewing skills. Instead of spending 2-5 hours/week going to meet ups, take 1 interview instead. Even with no preperation, you'll start to see the pattern in the types of questions people ask. Improve on your answers. Interview again.