I'm a veteran UI developer, AMA!

Ooo that’s a great question. I think you can already see the divisions (or subdivisions) along the line that stretches between the design and look and feel side of UI to the mechanics of it all (i.e. the JavaScript).

Also, there are people who love to work in the front end side of things but just aren’t design inclined, so would prefer to hand those parts to a dedicated person or team.

But the lines are already very blurry and the terms ‘backend’ and ‘front end’ feel a little loose to me. It feels like we talk a lot more around being a developer first and then which tech stack matches your skill set most closely. And there are people who specialise and niche off into day, accessibility or CSS or performance optimisation.

In the end, I think there will always exist a large Venn diagram between design and development and it doesn’t hurt for either side to dabble in the middle a little. It’s better for them, better for the team, and ultimately better for the user.

Great tip Phil, consider the AMA tag applied!

Micro front ends are one of those things that I’ve never been involved in. Not for the lack of interest, but just not working in an organisation that’s working with them.

They offer a wealth of benefits, such as breaking up larger codebases into smaller, manageable chunks and allow for the deployment through popular containerised platforms like Kubenetes.

However, you’ve got to be in a place that’s got them on the roadmap. It takes a team effort from the dev ops guys to the actual developers to implement the micro front end approach and there’s a learning curve for sure.

But yeah I’m all for them and hope to get involved one day in the future.

Howdy, to me, there is very little difference it’s just a bunch of titles.

I’ve seen UI used more in the title more recently and I really like the term as it feels a little more appropriate; after all it’s mainly the user interface that you’re dealing with.

For job seeking purposes I suppose it depends on what you’re looking for. The majority of jobs are still posted with ‘front end’ in there so I’d always look for that. However, there are a lot more technology-specific role titles creeping in too, so you can look out for ‘React developer’ or ‘Node js developer’.

Hey David, my pleasure.

I don’t really get bored with programming but I do find I have peaks and troughs of enthusiasm for other things that are part of it. For example, I had a break from social media and blogging last year as I just wasn’t feeling it, didn’t have the mojo. But it’s important to have breaks and come back stronger later. It does work and I’m back on it now.

I do get frustrated with some of it mind. Having to redo parts of code because of miscommunication or indecision, unnecessary meetings and so on. But I try to think of it as short term pain for long term gain and focus on the end goal.

I’ve had a few roles, predominantly as an individual within a team. I’ve rarely felt pressure to do more and I’ve alway spoken out when I’ve felt ‘put upon’. That said, I’ve always been happy to further my knowledge and expand my responsibilities especially when it came to mentoring juniors or taking charge of a specific area responsibility.

When I ran my agency, I did have to wear a lot of hats, but that’s part of running a business and it’s a steep learning curve. And it’s hard work.

The answer, like most things, is...it depends...

Tools are just that, tools. They'll likely have a specific task in mind and it's up to you to decide if that makes your life easier or harder. For example, you absolutely can code an entire website with nothing else than Notepad. Is it going to be easy? Not so much, but it can be done.

For me, it's a lot about feel and how much it empowers me, rather than restricts or hinders me.

For example, I use VS Code because it's awesome. It's so customisable, feels stripped back, but has a lot of depth and it just makes developing a pleasure.

However, if you were looking to delve into enterprise C# development, you'd probably be happier with Visual Studio as it offers more tools and areas to help you do your job.

As for web development in general, again, it really depends on what you want to achieve.

If you're looking at front end, then we're talking about HTML/CSS/JavaScript, probably with a modern app framework such as React/Preact or Vue.

If you're looking more back end then you've got the heavy hitters such as C# and other languages such as Python (becomming popular for big data and machine learning) and Ruby which are booming in popularity.

But there's nothing wrong with specialising in Wordpress development, however, as it does power something crazy like 1/5 of the web? It's a skillset that isn't going to go away overnight and even without WordPress, you'll have a solid set of PHP skills, which is still used be many a software development house today for building really useful things.

Does that help?

I build web since 1993 ;) and work with comp since 1984. basic :)
10 start
20 print
30 the end
voila :D

I think it partly depends on the process you’re using and the tools.

For example, we layout our proposed UI in Moqups (we used to us Balsamiq) which is a wireframing tool. It doesn’t give you defined units of size to have to stick to, but it lets us play with how best to represent the data to the user and helps us plan interactions, etc.

From there, well build the interface using our app’s design system which already has components and sizing all figured out which takes a lot of the issues you’re talking about away.

You could, however, use a more concrete tool like Sketch or Indesign, both of which are more geared towards creating ‘pixel-perfect’ representations of the end interface.

However you approach it, I think you’ve got to start with the aim of getting something close to what you want and then having a certain amount of acceptance that you’ll need to hone it during the actual build.

I think the best approach is to blend both with a leaning towards emulating how the user interacts with the thing you’re testing.

We largely cover four areas when testing:

• do certain elements show/hide on the front end (e.g. how the user interacts with the app)
• certain internal changes, state, functions are fired
• API calls being made
• the interactivity between components.

Oh and we’re also looking to build out a suite of visual regression testing. This approach physically interacts with the app/site/whatever and then matches screenshots to see if there have been negative/unexpected changes

Great question! I've always liked the separation of concerns: JavaScript lives in its corner and handles behaviour, HTML lives over there providing structure, and CSS does its pretty thing in another corner. It's partly how I learned and partly a orderly, 'everything in its box' mindset.

There's good reason for avoiding it too. If you've applied inline CSS here and there, it becomes difficult to hunt down weird styling issues or to make a more global change because you've overridden it in 10 other files.

Generally, I would avoid inline CSS as much as possible, same with conventions like '!important'. However, as is life, sometimes you can't avoid them and have to apply them. I think the skill is in applying them sparingly and for good reason, and that reason usually being that there is no other way (it does happen!).

I treat inline CSS like an emergency brake; useful in an emergency, but don't go pulling up at traffic lights using it!

I'm going with 'TTD' being a typo. If it's not then I don't even know what that is, let alone practice it :D

But TDD then also no. I love unit testing and it absolutely is an essential part of quality software. However, I've never actually worked anywhere that physically starts with the tests and then writes software to pass them. Even in places that claim to do TDD, it's always been software first and tests closely after.

To be honest, I feel that software development is a complex beast and it's difficult to write a bunch of tests first to then develop something that passes those tests. What you develop will likely need to change, sometimes part way through developing it (for many reasons) and it's just never been a practical way to develop, for me.

Firstly, I think it's worth putting out there that you absolutely do not need a CS or SE degree to get into development. It's worth saying because I see this on twitter a lot where people are really stressing about not having a CS degree and they'll never get a job. Here in the UK, it's never been a barrier for me or any other developers I know, but it might be different in, say, the States.

That said, doing a CS or SE, or even a maths degress will definitely help you in a number of ways:

Pros

• Allows for a more formal, structured approach to learning
• Will open some doors for you that require a formal qualification
• They're the best way to learn some subjects at a depth that you'll need for the job. For example, 3D graphics or games development
• You'll learn important, fundamental programming principles, such as SOLID, that you might otherwise miss

Cons

• It's expensive...like really expensive, wherever you live.
• You're going to learn a lot of extraneous things that you won't need. For example, I did a computing A-level and learned binary maths, like complex stuff with division and all sorts. I have never ever come close to needing this.
• It's a longer commitment that can put you slightly further behind your peers who just started developing in, say, JavaScript and React

I'm sure there are many more on each side that I've missed.

However, we've never lived in a better time to start developing and there are tons of routes into the profession; be it books, YouTube, online courses, and awesome resources like Free Code Camp.

I think the key thing is that there is no 'wrong' way in, but it's up to the individual to assess their needs and see if it's right for them.

Full disclosure, I never went to university and don't have a degree. I felt that university wasn't right for me, but a life in the Matrix was :)

Oooo let me rack me brains in the ‘repressed’ section 😂

IE6 was a particularly harrowing browser experience to work with as it had so many flaws and hacks you had to do to get things looking the way you wanted.

Apps and libraries wise, one of the worst things I’ve had to work with was a 4000+ lines file that did all sorts of things with Google Maps. It was just all over the shop and not even commented in any meaningful way. Hard hard work to deal with.

I don’t really have a most-disturbing, but I’m a big believer in good documentation. I’ve missed on using potentially fabulous libraries because they’re just horribly documented and require too much working out of how it all works.