Posts

Posted on

As an industry we still don’t know how to effectively transfer ‘experience’ to new developers

New developers start their careers with a limited grasp of the ‘what’, the basics of how to write code in a given language and tech stack, but the deeper understanding of the ‘why’ and how to evaluate potential solutions and pick the most effective solution given known constraints comes much later with experience.

Experienced developers have knowledge of what they’ve seen work and not work from past development projects and can use this knowledge to make educated decisions. Given any problem, having seen multiple solutions applied on past projects allows you to draw from that knowledge of seeing what has worked and not worked and evaluate what solution is the better option when you see this problem again (or something similar).

Experience and knowledge is hard to pass on from one developer to the next. Programming techniques like iteration and conditional statements can be taught and easily learned, but an appreciation of why solution A is more effective than B is harder to convey, usually because the reasons why one solution is better depends on the context and an understanding of the current constraints that you need to work with. Being able to identify what’s important and what is not is a skill that more experienced developers develop over time, but it’s hard to teach.

Experienced developers add obvious value to any project or team, they provide leadership and the benefit of being able to make informed decisions based on their prior experience that lead to better outcomes for the business with a higher degree of certainty (compared to randomly picking a possible solution without knowing if it’s feasible or the most effective option or not).

The problem we have as an industry is that we still haven’t worked out an effective approach for conveying this experience to other new developers. You can gain experience by putting in the time and effort by working on a variety of different software development projects, but there doesn’t appear to be any easy fasttrack approach to package this information and hand to another developer. Can software development experience be ‘knowledge transferred’ to another developer? Maybe not. Maybe you just have to invest the time to gain experience the hard way.

Misunderstanding or under valuing the experience that an experienced developer brings to a team is a common mistake of someone who does not fully appreciate the complexity of software development. All developers are not equal, and one developer cannot be equally exchanged for another. If we can find an effective approach to easily fastrack the passing of experience from one developer to another, this would massively accelerate the growth of new developers, but maybe the reality is experience just has to be gained the hard way.

Posted on

Differences between US and UK Amateur Radio license rules and restrictions – part 3: Callsigns

Continuing my posts looking at the differences between US and UK amateur radio licenses (part 1, part 2), I’m now taking a look at callsigns.

In the US, callsigns are assigned using the following format (described in FCC doc here):

Technician

For regions 1 through 10:

  • K, N or W prefix + additional letter + region 1 through 10 + 3 letter suffix (aka 2 by 3)
  • Other regions beyond 10 have slight variations in the prefix, such as KH for Hawaii (Region 13)

General

For regions 1 through 10:

  • K, N or W prefix + region 1 through 10 + 3 letter suffix (aka 1 by 3
  • Other regions beyond 10 have slight variations in the prefix, such as KH for Hawaii (Region 13)

Amateur Extra

For regions 1 through 10:

  • K, N or W prefix + region 1 through 10 + 2 letter suffix (aka 1 by 2)
  • 2 letter prefix starting A, N, W or M + region + 1 letter suffix (aka 2 by 1)
  • 2 letter prefix starting A + region + 2 letter suffix (aka 2 by 2)
  • Other regions have slight variations in prefix

UK Licences

For UK licenses there are similar differences between Foundation, Intermediate and Full, but with the addition of a required ‘Regional Secondary Locator’ (RSL) character to indicate the country where you are transmitting from:

Foundation License

Prefix starts:

  • M#3
  • M#6
  • M#7

… where # is the placeholder for the RSL. Interestingly, the UK licenses are issued showing the # where you are expected to substitute your RSL yourself.

RSLs used are:

  • none : England (E is not used for Foundation callsigns)
  • M : Scotland
  • I : Northern Ireland
  • EI : Ireland
  • W : Wales
  • D : Isle of Man
  • U: Guernsey
  • J : Jersey

Intermediate

Prefix starts:

  • 2#0
  • 2#1

RSLs used are (note ALL RSLs are used, including E for England, where this is not used for Foundation and Full):

  • E : England
  • M : Scotland
  • I : Northern Ireland
  • EI : Ireland
  • W : Wales
  • D : Isle of Man (for Douglas, capital of Isle of Man)
  • U: Guernsey
  • J : Jersey

Full

  • M#0
  • M#5
  • G#0 to G#8

RSLs used are:

  • none : England (E is not used for Full callsigns)
  • M : Scotland
  • I : Northern Ireland
  • EI : Ireland
  • W : Wales
  • D : Isle of Man
  • U: Guernsey
  • J : Jersey

Optional callsign suffixes

/A : used to indicate operating from a different address than your normal station location, if the alternative location has an address

/M : operating mobile, e.g. in a car

/P : away from main station location, but NOT at an address that has a postal address, e.g. if camping in a field

  • note that /P does not include operating an HT when mobile which is /M

Posted on

Updating Personal Access Tokens used with Github Actions

A while back I set up a Github Action to build and deploy an app on each code commit. Since it’s good practice to set an expiry date on your Personal Access Tokens, at some point they will expire and you’ll need to update them.

In my project I reference the Access Token using a Github Secret stored in the settings for the project:

To update the expired or about to expire token:

  • create a new Personal Access Token in your account settings
  • copy the new token value, update the Secrets in your project and paste the new value

Done!

Posted on

Differences between US and UK Amateur Radio license rules and restrictions – part 2

A while back I posted this article about some of the differences I’ve noticed while studying for a UK Amateur Radio license compared to the US license rules. I’ve just come across a few more about geographic restrictions, which are probably amongst the most curious of the license rules.

US Geographic Restrictions

In the US, the Part 97 rules define a couple of geographic areas where you’re not allowed to transmit.

97.303 states:

(m) In the 70 cm band:

(1) No amateur station shall transmit from north of Line A in the 420-430 MHz segment. See §97.3(a) for the definition of Line A.

And defines Line A as:

(30) Line A. Begins at Aberdeen, WA, running by great circle arc to the intersection of 48° N, 120° W, thence along parallel 48° N, to the intersection of 95° W, thence by great circle arc through the southernmost point of Duluth, MN, thence by great circle arc to 45° N, 85° W, thence southward along meridian 85° W, to its intersection with parallel 41° N, thence along parallel 41° N, to its intersection with meridian 82° W, thence by great circle arc through the southernmost point of Bangor, ME, thence by great circle arc through the southernmost point of Searsport, ME, at which point it terminates.

The reason for this restriction is that Canada does not allow 70cm Amateur Radio usage between 420-430Mhz and so this corridor along the North US border with Canada and between Alaska and Canada is to prevent interference with other primary users of 420-430MHz.

There are a couple of other location specific restrictions stated in Part 97 for US operators:

(2) Amateur stations transmitting in the 420-430 MHz segment must not cause harmful interference to, and must accept interference from, stations authorized by the FCC in the land mobile service within 80.5 km of Buffalo, Cleveland, and Detroit. See §2.106, footnote US230 for specific frequencies and coordinates.

Since 70cm band usage is on a secondary user basis, restrictions are to prevent interference with primary users in these areas.

The US Part 97 rules also mention restrictions for the National Radio Quiet Zone in Virginia – this location contains the Green Bank Observatory and a Naval Research Station. Part 97.203 mentions restrictions to automated beacon stations in this area.

Another interesting restriction on 70cms is the power restriction to 50w in locations near to particular military bases. Having lived in the Sacramento Valley area, this 70cms restriction is known to the local clubs and operators as a measure to avoid interference within 150 miles of the PAVE PAWS radar at Beale AFB.

UK Geographic Restrictions

I’ve only come across these similar UK restriction so far, stated on the license bandplan:

431 to 432 MHz is not available within 100 km radius of Charing Cross, London

As UK 70cm usage is as a secondary user, this is again to avoid interference to primary users in this band.

On 2m:

Beacons may be established for DF competitions except within 50 km of TA 012869 (Scarborough)

If anyone knows what is specifically at this location leave a comment below, although this RSGB page and map may give some clues since Menwith Hill is also mentioned here as another area with restrictions.

Proudly powered by WordPress