Post: #26

(12-26-2017 04:12 AM)roid Wrote:  HackerNews and lobste.rs are more like news sites, I think you should not count it as work. However, I am interested to know how much time you devote to learn new language in case the current language you're working on is fading away.

The time to learn a new language decreases exponentially once you are familiar with a few languages from different paradigms. Becoming an expert in a particular language takes a lot of time, of course, but you don't need to be an expert to have it in your toolbelt. Reading a few articles about the language, reading a syntax reference, studying some source code and writing a small test project is enough to get started and can be done over the course of a weekend. If you don't want to do it in the weekend, you can break it down over the week. Once you have done that, you can decide whether to drop it or to invest more by writing a larger project or looking for work in that language. I believe this is the way most seasoned programmers learn new languages. They don't sit down every day and study and practice for a few hours until they're good with the language. They eat around the edges using the accumulated knowledge that they already have.

HackerNews and lobste.rs are not just news websites. They're more like reddit in the sense that anything can be linked and upvoted. They're important tools from a market perspective because they give you an insight on the problems being faced by people in the industry and the approaches they're using to solve them. There are a lot of articles in HN talking about a resolution to a particular problem using a certain language or framework. In addition, HN has lots of introductory articles about new technologies that are coming up. It's easy to pick up the trends when you're reading those every day.

For example, recently there was a lot of traction in an article about the Red programming language. I had never heard about that language before, but the article was interesting. I didn't learn Red from reading it, but I learned something about Red. And it enticed my interest enough to click through the website and see code samples. Now I know what Red looks like and have an idea about how it works. Searching for red language in HN tells me this is not the first time the community has been vocal about Red in the last couple of years. That tells me Red should be on my radar. Maybe it will never be more than a curiosity, but maybe it will amount to something. If I start seeing articles about people using Red to solve real problems, I might decide to explore it further and spend a Saturday writing something in Red. Then I'll really know.

Of course I can not count this as work, but it isn't purely entertainment either. It's learning about things that interest me but that are also useful for my work. That's why I said this isn't a problem as long as you like what you're doing.

Post: #27

(12-23-2017 01:40 PM)lazy Wrote:  Career:

Yes, the software engineering world is constantly flooded by new technologies and you need to learn or read about all of them if you want to stay on top of your game. If you don't enjoy doing so, you won't succeed, unless you find a specific niche that's more or less static but still in demand (think COBOL devs). Personally, I don't think that's such a major problem. You just have to like what you're doing. I read nerdy shit about programming languages and frameworks all the time because I actually find it interesting.

Keeping up with as much tech as possible is important, but I think there are a few ways to make it easier. The most obvious one, as you mention, is to like what you're doing.

The other is to make a winning bet on key fundamental tools and technologies. The idea is to identify and become fluent in a technology area (not necessarily a programming language) that is:

1. Stable and long-lived.
2. Powerful and flexible with solid theoretical foundations. (Surprisingly few technologies manage to really nail all three of these.)
3. Widely deployed.
4. Well-documented and preferably open-source (there is much better potential to develop substantial expertise if the source code is freely available to peruse when you want to really understand something).

Unix (Linux) is a good example. Many core features of Unix have not changed substantially in decades and are still used today. Text processing commands like sed, awk, and grep are as useful today as they ever were, thanks to the consistency and standardization of the IO streams like standard in, standard out, and standard error.

Relational Databases are another (MySQL, Postgresql, sqlite, Oracle). Modern alternatives are mostly solving new and different problems that pushed traditional RDMS beyond their limits. There are still a huge class of problems for which an RDBMs is the best solution.

If you are an expert in Unix or RDBMS, and can program them with a popular language, you will be able to apply those skills in many different domains for a long time.

A contrasting example would be something like PHP. It passes a few of the criteria-- it's reasonably stable and long-lived, there's a lot of documentation and it's widely deployed, and people that use it tend to "get things done" with it. But it's not a deep technology. It's just one alternative for template-based server-side web development.

Which is not to say "don't learn PHP," just don't make it the foundation of your skill set.

For front-end/browser/web/mobile development it is a somewhat harder call to make. The browser landscape has been chaotic and fast-moving mess for a long time. It's hard to pinpoint any one technology that you can safely say won't be obsolete in a few years. Plus, since front-end development tends to be oriented around interactive UIs and media, shifting user needs and expectations player a more substantial role influencing software available.

Post: #28

UNIX skillsets are mostly useful for system admin. MySQL, Oracle, etc are for DBAs. I think for developers, they need to realize that ageism is going to hit them sooner or later. The faster they accept that, the better.

(12-26-2017 12:20 PM)Blaster Wrote:  

(12-23-2017 01:40 PM)lazy Wrote:  Career:

Yes, the software engineering world is constantly flooded by new technologies and you need to learn or read about all of them if you want to stay on top of your game. If you don't enjoy doing so, you won't succeed, unless you find a specific niche that's more or less static but still in demand (think COBOL devs). Personally, I don't think that's such a major problem. You just have to like what you're doing. I read nerdy shit about programming languages and frameworks all the time because I actually find it interesting.

Keeping up with as much tech as possible is important, but I think there are a few ways to make it easier. The most obvious one, as you mention, is to like what you're doing.

The other is to make a winning bet on key fundamental tools and technologies. The idea is to identify and become fluent in a technology area (not necessarily a programming language) that is:

1. Stable and long-lived.
2. Powerful and flexible with solid theoretical foundations. (Surprisingly few technologies manage to really nail all three of these.)
3. Widely deployed.
4. Well-documented and preferably open-source (there is much better potential to develop substantial expertise if the source code is freely available to peruse when you want to really understand something).

Unix (Linux) is a good example. Many core features of Unix have not changed substantially in decades and are still used today. Text processing commands like sed, awk, and grep are as useful today as they ever were, thanks to the consistency and standardization of the IO streams like standard in, standard out, and standard error.

Relational Databases are another (MySQL, Postgresql, sqlite, Oracle). Modern alternatives are mostly solving new and different problems that pushed traditional RDMS beyond their limits. There are still a huge class of problems for which an RDBMs is the best solution.

If you are an expert in Unix or RDBMS, and can program them with a popular language, you will be able to apply those skills in many different domains for a long time.

A contrasting example would be something like PHP. It passes a few of the criteria-- it's reasonably stable and long-lived, there's a lot of documentation and it's widely deployed, and people that use it tend to "get things done" with it. But it's not a deep technology. It's just one alternative for template-based server-side web development.

Which is not to say "don't learn PHP," just don't make it the foundation of your skill set.

For front-end/browser/web/mobile development it is a somewhat harder call to make. The browser landscape has been chaotic and fast-moving mess for a long time. It's hard to pinpoint any one technology that you can safely say won't be obsolete in a few years. Plus, since front-end development tends to be oriented around interactive UIs and media, shifting user needs and expectations player a more substantial role influencing software available.

Post: #29

(12-26-2017 12:20 PM)Blaster Wrote:  The other is to make a winning bet on key fundamental tools and technologies.

Completely agree.

(12-27-2017 04:01 AM)roid Wrote:  UNIX skillsets are mostly useful for system admin. MySQL, Oracle, etc are for DBAs.

Those days are long gone. DBAs are an increasingly rare figure. You are unlikely to run into them unless you're working for a large company or for an old school company. Even if you do have a DBA around, his job will probably be reviewing and optimising what you do, as well as DB tuning. 90% of the RDBMS work will still be done by you.

System admins and devops engineers are common, but Unix is still required knowledge. If you are programming for an Unix system but can't confidently deploy and debug your own program, how am I supposed to trust you? You should be comfortable debugging problems in your deployment target.

Programmers in 2018 are expected to know a lot. Especially in the freelancing world. Not knowing relational databases or Unix will be an impediment for you, unless you're an expert in a field that's in high demand.

Post: #30

Right. A DBA as a dedicated position might be less common now. But databases are a lot more common now than they used to be. I suspect that 20 years ago, you had a greater proportion of enterprise DBAs working on internal software at big companies. Whereas now there are hundreds or thousands of database-backed products and services of all different sizes and scopes. Those products and services all place different demands on software engineers, from a one-click Wordpress install to an online video game.

Consider the Blizzard job listing page. Browsing over the Senior Software Engineer postings, any of the "Server" or "Feature" engineers have Databases either as a requirement or a plus. Now consider that there are hundreds if indie game developers doing the similar things on a smaller scale that didn't exist at all a decade ago.

You'll also see frequent mention of Linux and C/C++, as well as a variety of soft skills.

Obviously, you're not likely to get a remote work opportunity with Blizzard. For one thing, the videogame industry is highly competitive. They're the only companies where I've ever had to sign an NDA just to be allowed in the door. But their job descriptions look reasonably serious and straightforward (neither try-hard like a Silicon Valley startup nor horridly mangled by a clueless Human Resource department).

Post: #31

So, half a year has passed and I want to come back to the topic. Unfortunately nothing has changed so far with my career into direction of location independence (see start post of his thread). Kick me in the ass if you think I should have changed anything, or have some good words for me if you think it s fair to first just get more experience in my field and later starting out the location independence adventure.

The main question I am struggling to make a clear decision is:
should I stay in the more technical field of embedded systems , microcontrollers , programming in C/C++? Or should I make a switch into the probably most classical digital nomad career, web development? So far I can t see a clear path in front of me how to do the remote thing in my technical field. I m sure it is possible somehow with today s technologies, and my work is 99 % behind a computer screen, using a soldering iron maybe once per month, there must be some niches that eliminate this 1% completely and can be done just from a laptop, but the industry is quite conservative and often the kinds of projects not a perfect fit for remote work. Projects are longterm and heavily specialised, big efforts for training a newbie. In job interviews I was several times told they are looking for someone really longterm and how I can convince them that my intent is to stay with them.

And my biggest problem that I can t find a laid out path how to make it happen in this field. No youtube-hero for me advertising this path, let alone meeting some real person and getting advice in this field. My colleagues have other goals in life. And in the digital nomad scene everyone seems to do web development if they are software guys. Can t decide if I should switch.

Pluses for Embedded systems:

- from all I hear it s paid higher and has much less competition than web development, at least if you are really good and have lots of experience (which is still a long road for me)

- I already invested a lot. Studying electrical engineering (instead of CS) , 3 internships and now for already 10 months a job in this field. There s still a long road ahead, but I already put time and effort into it. In Web development, although I have a good foundation from my self studies, I would start as a newbie in the professional world.

Pluses for web development:
- the classic DN career
- low entry barrier, much faster ready for creating real value, even if not yet a super hero.
- smaller and shorter projects someone can come in, work, deliver and roll on to the next gig (right???)
smaller projects someone can do more or less alone as a freelancer
- the overwhelming majority of jobs on freelancing sites as well as remote Job sites are in Web Development
- no dependency on hardware, so perfectly suitable for remote work
- a mostly open minded industry in terms of unconventional working models
- resources for learning mostly available for free online

Tell me your opinions please. And if there is any embedded developer out there, please raise your hand.

Post: #32

I work in embedded field as well and I agree, it's difficult to completely break free from the physical office. Apart from needing to carry a bunch of physical equipment, most companies are also culturally hostile to remote work, compared to pure SW companies. Some of my colleagues do work remotely, but very rarely 100% or even near. Because remote working culture is not in the blood of embedded SW companies, these 100% guys slowly seem to become outcasts and left out of the best opportunities. This is due to the fact that people still prefer face to face communication, even though tools like Slack are smoothing things out a little bit.

Of course if you are a rare specialist in a niche skill, you can basically do what you want, due to lack of competition.

That said, after closer consideration, personally I would not even want to go 100% remote. Honestly most of the time my work is quite boring (been doing this for 10+ years) and doing it remotely without any (real) human interaction would make it even worse. On top of that, due to deadlines it's also often stressful, and the lethal combination of boredom+stress would burn me out within a year.

These facts have led me to consider a compromise where I would grind at the office for 7-8 months per year and leave 4-5 months for travel. On the road I would offer to work for 16-24 hours/week to keep my employer happy and to prevent other people from taking over my tasks (thus making myself obsolete). Unfortunately I'm a rather average employee so I'm not sure if I have enough leverage to pull it off. Even if I can, the downside is I still need to grind those 7-8 months at the office, but even that's a hell of an upgrade from the current 10.5 months.

But even to accomplish that I need to focus on building skills that 1) make me difficult to replace 2) can be done remotely. In the past I was sloppy about this and now I pay the price of being stuck at the office.