Wednesday, September 19, 2018

MacOS Preview.app has a Signature Tool

When I receive a PDF file to be signed and returned I have generally printed it out to sign and scan back in... like an animal, as it turns out. On a MacOS system there is a convenient way to add a signature to a PDF file without needing to print it, using only the Preview.app which comes with the system.

In the toolbar is a squiggly icon with a drop down menu:

Clicking it allows one to create a signature by either signing with a finger on the trackpad, or writing a signature on a piece of paper for the camera to scan in. The camera option does a good job of edge detection to extract only the writing and not shadows on the paper.

The resulting signature can then be added to the document and dragged to the right spot.

Saturday, September 15, 2018

The Arduino before the Arduino: Parallax Basic Stamp

I recently had cause to dig down through the layers of strata which have accumulated in my electronics bin. In one of the lower layers I found this bit of forgotten kit: the Parallax Basic Stamp II. This was the Arduino before there was an Arduino, a tiny microprocessor aimed at being simple for hobbyist and low-volume commercial use.

The Basic Stamp line is still sold today, though with designs developed over a decade ago. The devices have enough of a market to remain in production, but are otherwise moribund. The past tense will be used in this blog post.

The Basic Stamp line dates back to the early 1990s. The Basic Stamp II shown here was introduced in 1995. It used a PIC microcontroller, an 8 bit microprocessor line which has been used in deeply embedded applications for decades and is still developed today. The PIC family is a product from Microchip Technology, the same company which now supplies the AVR chips used in the Arduino after acquiring Atmel in 2016.

The PIC contained several KBytes of flash, which held a BASIC interpreter called PBASIC. An external EEPROM on the BS2 board contained the bytecode compiled user BASIC code. Though it may seem an odd choice now, in the early 1990s the choice of BASIC made sense: the modern Internet and the Tech industry did not exist, with the concordant increase in the number of people comfortable with developing software. BASIC could leverage familiarity with Microsoft GW-BASIC and QBASIC on the PC, as MS-DOS and Windows computers of this time period all shipped with BASIC. Additionally, Parallax could tap into the experience of the hobbyist community from the Apple II and Atari/Commodore/etc.


' PBASIC code for the Basic Stamp
LED         PIN 5
Button      PIN 6    ' the BS2 had 16 pins
ButtonVal   VAR Bit  ' space is precious, 1 *bit* storage
LedDuration CON 500  ' a constant

' Init code
OUTPUT LED
INPUT  Button

DO
 ButtonVal = Button                 ' Read button input pin
 FREQOUT LED,LedDuration,ButtonVal  ' PWM output to flicker LED
 PAUSE 200                          ' in milliseconds
LOOP

PBASIC supported a single thread of operation, the BASIC Stamp supported neither interrupts nor threads. Applications needing these functions would generally use a PIC chip without the BASIC interpreter on top. Later Stamp versions added a limited ability to poll pins in between each BASIC statement and take action. This seemed aimed at industrial control users of the stamps, for example Disney used BASIC Stamps in several theme park rides designed during this time frame.

A key piece of the Arduino and Raspberry Pi ecosystems is the variety of expansion kits, or "shields," which connect to the microprocessor to add capabilities and interface with the external world. The ecosystem of the BASIC Stamp was much more limited, suppliers like Adafruit were not in evidence because the low volume PCB design and contract manufacturing industry mostly didn't exist. Parallax produced some interesting kits of its own like an early autonomous wheeled robot. For the most part though, hobbyists of this era had to be comfortable with wire-wrapping.

Saturday, September 8, 2018

code.earth hackathon notes

Project Drawdown is a comprehensive plan proposed to reverse global warming. The project researchers analyzed and ranked scenarios according to the potential reduction in carbon levels, and analyzed the costs.

Project Drawdown will continue the analysis work, but is moving into an additional advocacy and empowerment role of showing governments, organizations, and individuals that global warming can be mitigated and providing detailed guidance on strategies which can work. The audience for the project's work is expanding.

This places new demands on the tools. The tooling needs to be more accessible to people in different roles, and provide multiple user interfaces tailored to different purposes. For example, the view provided to policymakers would be more top-level, showing costs and impacts, while the view for researchers would allow comparisons by varying the underlying data.

The code.earth hackathon in San Francisco September 5-7, 2018 implemented a first step in this, starting to move the modeling implementation from Microsoft Excel into a web-hosted Python process with Excel providing the data source and presentation of the results. This will separate the model implementation from user interface, making it easier to have multiple presentations tailored for different audiences. It will still be possible to get the results into Excel for further analysis, but web-based interfaces can reach much wider audiences able to act on the results.

I was at the hackathon, working on an end-to-end test for the new backend, and plan to continue working on the project for a while. Global warming is the biggest challenge of our age. We have to start treating it as such.

Sunday, September 2, 2018

Carbon Capture: Cryogenic CO2 Separation

Sublimation is a phase change directly from a solid to a gas without transitioning through an intermedia liquid state. Desublimation is the opposite, where a gas crystalizes into a solid without becoming a liquid first. The most well-known example of desublimation is snow, where water vapor crystalizes into tiny bits of ice. When water vapor in the cloud first condenses into liquid and then freezes, the result is hail not snow.

Interestingly, and quite usefully for carbon capture, carbon dioxide will desublimate at -78 degrees Centigrade. This is a considerably higher temperature than the main components of the atmosphere like nitrogen and oxygen, and means that as air gets very cold that CO2 will be among the first components to turn into ice crystals. This allows the CO2 crystals to be harvested.

Several companies have working technology in this area:

  • Alliant Techsystems (now defunct) and ACENT Laboratories developed a supersonic wind tunnel which compresses incoming air, causing it to heat up, then expands the supersonic airflow causing it to rapidly freeze. CO2 crystals can be extracted via cyclonic separation, relying on the mass of the frozen particles.

  • Sustainable Energy Solutions in Utah uses a heat exchanger process to rapidly cool air, harvest the CO2 crystals, then reclaim the energy spent on cooling before exhausting the remaining gases.

Wednesday, August 29, 2018

Google Software Engineering Levels and Ladders

Google (now Alphabet) hires a lot of engineers every year. There are articles out there about the interview process and how to prepare, and I do definitely recommend spending time in preparation. Google interviews for software engineers mostly do not focus on the candidate's resume or prior experience, instead asking technical questions on various topics and coding. You'll do better if you mentally refresh topics in computer science which you have not recently worked with.

This post focuses on a different area: how to evaluate an engineering job offer from Alphabet. The financial aspects will presumably be clear enough, but the career aspects of the offer may not be. This post will attempt to explain what Google's engineering career progression looks like.

There are two concepts: ladder and level. The ladder defines the role you are expected to do, like manager or engineer or salesperson, while the level is how senior you are in that role.

Like many Tech companies, Google has parallel tracks for people who wish to primarily be individual contributors and for people who wish to primarily be managers. This takes the form of two ladders, Software Engineer (universally abbreviated as "SWE") and Software Engineering Manager. Google does allow people on the SWE ladder to manage reports, and allows people on the Manager ladder to make technical contributions. The difference is in how performance is evaluated. For those on the SWE ladder the expectation is that at least 50% of their time will be spent on individual contributing engineering work, leaving no more than 50% on management. For those on the Manager ladder the expectation is more like 80% of the time to be spent on management. People on one ladder veering too far out of the guidance for that ladder will be encouraged to switch to the other, as performance evaluations will begin to suffer.


 

Software Engineer Ladder

The levels are:

  • SWE-I (Level 2) is a software engineering intern, expected to be in the junior or senior year of a four year degree program.
  • SWE-II (Level 3) is an entry level full-time software engineer. An L3 SWE is generally someone who recently graduated with an undergraduate or Master's degree, or equivalent education.
  • SWE-III (Level 4) is someone with several years of experience after graduation, or for someone who just finished a PhD in a technical field.
  • Senior Software Engineer (Level 5) is the level where a software engineer is expected to be primarily autonomous: capable of being given tasks without excessive detail, and being able to figure out what to do and then do it. A software engineer advances to L5 primarily by demonstrating impact on tasks of sufficient difficulty. When hiring externally, six to ten years of experience is generally expected.
  • Staff Software Engineer (Level 6) is the level where leadership increasingly becomes the primary criteria by which performance is judged. Many, though by no means all, SWEs begin managing a team of engineers by this point in their career. When hiring externally, ten or more years of experience are generally expected.
  • Senior Staff Software Engineer (Level 7) is essentially L6 with larger expectations. Guidance for years of experience begins to break down at this level, as most candidates with ten or more years experience will be hired at Level 6 unless there is a strong reason to offer a higher level. Involvement of the hiring manager or strong pushback by the candidate can sometimes push the offer to Level 7.
  • Principal Software Engineer (Level 8) is the first level which is considered an executive of the Alphabet corporation for the purposes of remuneration and corporate governance. Principal Software Engineers drive technical strategy in relatively large product areas. SWEs at level 8 or above are relatively rare: the equivalent level on the manager ladder will routinely have five or more times as many people as on the SWE ladder. By this level of seniority, most people are focussed on management and leadership.
  • Distinguished Software Engineer (Level 9) drives technical strategy in efforts spanning a large technical area.
  • Google Fellow (Level 10) is the same level as a Vice President, expected to drive technical strategy and investment in crucial areas.
  • Google Senior Fellow (Level 11) is for people like Jeff Dean and Sanjay Ghemawat.

Most external hiring for software engineers is for L4 through L6, with L7 also possible though less common. Hiring externally directly to L8 and L9 does happen, but is quite rare and demands the direct sponsorship of a high-level executive like a Senior Vice President of a Google Product Area or CEO of an Alphabet company. For example James Gosling and David Patterson both joined the company as L9 Distinguished Engineers.

Also notable is that the external hiring process and the internal promotion process are entirely separate, and at this point have diverged substantially in their calibration. It is fair to say that Alphabet substantially undervalues experience outside of the company, or perhaps overvalues experience within the company. Someone with ten years experience externally would be hired at L5 or L6, while ten years within the company can make it to L7 or L8.


 

Software Engineering Manager Ladder

The levels are:

  • Manager, Software Engineering I (Level 5) is the first level on the manager ladder. It is expected that people will have a few years experience in the field before they begin managing a team, and therefore the Manager ladder starts at level 5. Manager I will typically lead a small team of engineers, five to ten is common.
  • Manager, Software Engineering II (Level 6) is typically a manager of a team of ten to twenty, sometimes a mixture of direct reports and managing other managers. When hiring externally, 10+ years of experience is expected.
  • Manager, Software Engineering III (Level 7) begins the transition to be primarily a manager of managers. Teams are larger than L6, typically twenty to forty.
  • Director (Level 8) is the first level which is considered an executive of the Alphabet corporation for the purposes of remuneration and corporate governance. Directors are mostly managers of managers, and typically lead organizations of forty up to several hundred people.
  • Senior Director (Level 9) is basically a secret level at Google: all of the internal tools will show only "Director," and by tradition promotions to Senior Director are not publicly announced. Senior Directors may lead slightly larger organizations than L8 Directors, though mostly it provides a way to have a larger gap between Director and VP while still allowing career progression.
  • Vice President (Level 10) typically leads organizations of hundreds to thousands of people. Their direct reports will typically be Directors and will be second to third level managers themselves.
  • Vice President II (Level 11), like Senior Director, is shown only as "VP" in internal tools and provides a way to maintain a larger gap between VP and SVP while still allowing managers to advance in their careers.
  • There are executive levels beyond L12, notably Senior Vice Presidents of Google divisions and CEOs of other Alphabet companies. This blog post is not a good guide to hiring for those levels, if you happen to be such a candidate. Sorry.

When hiring managers externally, L5 through Director is most common. Above Director is rare and generally only happens with the sponsorship of a high level executive. However where SWE hiring essentially tops out at L9, manager hires can come in at almost any level given sufficient sponsorship. Alphabet hires CEOs for its affiliated companies (John Krafcik, Andrew Conrad) and Google SVPs (Craig Barratt, Diane Greene) externally.


 

Other ladders equivalent to SWE

There is one other software engineering role at Alphabet which is parallel to the SWE/Software Manager ladders: Site Reliability Engineer or SRE. The individual contributor ladder is called SRE-SWE — for historical reasons, as there used to be an SRE-System Administration ladder which is no longer hired for. There is also an SRE Manager ladder. The levels on SRE-SWE and SRE Manager roughly correspond in responsibilities and years of experience to the SWE and Software Manager ladders described above, though the nature of the work differs.

SRE is equivalent to SWE in that at any time, an SRE can choose to relinquish the SRE duties and transfer to the SWE ladder and SRE Manager can switch to the Software Manager ladder. If originally hired as an SRE, they can also generally switch back if they choose to to do in the future. Engineers hired as a SWE who wish to transfer to SRE require a bit more process, often via an internal training program to serve a rotation as an SRE.


 

Other ladders NOT equivalent to SWE

SETI, for Software Engineer in Tools and Infrastructure, is another engineering ladder within Google. Though recruiters will make the claim that it is just like being a SWE, transfers from SETI to SWE require interviews, acceptance by a hiring committee, and approval of the SVP who owns the SWE ladder. Though often successful, transfers from SETI to SWE are not automatic and do get rejected, at both stages of the approval process. As such, recruiter claims that it is just like being a SWE are not accurate. The recruiter just has an SETI role to fill.

Only accept an SETI role if automated testing and continuous software improvement are really passions. Projects listing SETI openings will be less numerous than SWE, though will often be more focussed on automation and quality improvement. In many cases, internal transfers to projects which list a SWE opening will accept an SETI applicant, but not always. Being on the SETI ladder will therefore be slightly limiting in choice of projects for internal mobility.

There are other ladders which also involve software development but are even further removed from the SWE ladder, notably Technical Solutions Engineer (TSE) and Web Solutions Engineer (WSE). As with SETI, transfers to the SWE ladder require interviews and approvals. Recruiter claims that TSE or WSE are "just like being a SWE" are not accurate, as people on these ladders cannot internally transfer to projects which have a SWE opening. They can only transfer to TSE/WSE openings, which limit the choice of projects.