Following up on my previous post on ISND (International Standard of Network Documentation). This post is about how you can do good network diagrams.
But first I have to correct my self, based on the feedback I got on my previous post.
I wrote that "builders don't get a 10 page report describing how the house should be built" and have been corrected. In the construction business, there is written documentation. There is documentation on what materials to use, which codes to follow and general descriptions. If you include the public codes, there's a lot of written documentation.
We are lucky in that our industry doesn't have public codes regulating how networks should be built. There are "codes" in the private domain, which a customer may refer to when requesting a solution but no public ones.
So to correct myself, I'm not suggesting, that you don't produce any written documentation at all!
You should.
But you need to separate what goes into your written documentation and what goes into your diagrams. The diagram is your blueprint - your building instruction, this tells you what to build. Your written documentation is the detail, this tells you how to build it.
Since this post is about diagrams, I've decided that I might make a follow up on this one, to talk about the the written documentation.
To recap from my last post, I stated that you need to make different diagrams for different purposes. Here I will give you some examples of how to do that. This is obviously not going to be complete standard, I don't have the time and space to write that here and you couldn't be bothered to read it. Instead I will try to give you an idea of the concepts you should be using and which ones to avoid, with some examples to get you started.
Keeping the architects drawings in mind, we start by dividing our network diagrams into two categories. The design sketch, this is our High Level Design (HLD) and the technical drawings, these are our Low Level Designs (LLDs).
The purpose of the HLD is to conway an idea, a vision, to a client. It shows the big picture. These are the things you sketch on a whiteboard using your classic iconography and most of you should be familiar with this. But remember: Your HLD contains no technical information. Don't be tempted to add IP addresses, VLAN numbers and so on. They should be readable on A3 size paper. Split them up. Just like the architect has sketches of different parts of the house, you to should have diagrams of different parts of the network. When you do HLDs you must think about your client. He should be able to understand them and recognize the elements, that he has requested for the design.
The audience of your LLD are the people how are going to build the network or extend it in the future. Here you must remember to keep everything in diagrams - often people attach a text to the diagrams explaining how it works. This should not be necessary if you do your diagrams correctly and put the detailed information into the written documentation.
In your LLD you always need to make diagrams for your Layer 1, Layer 2 and Layer 3. In addition, you can make other functional diagrams, that are needed for your design, such as rack diagrams, power diagrams, routing diagrams, security diagrams and so on. Which ones are required, depends on your design. You should be in no doubt as to where to put what information.
Remember to put in a legend explaining your symbols.
Any information you need to add, should be drawn with basic technical information on the elements, such as IP addresses, device names and so on. If you need to reference detailed information in the written documentation, do that through the legend as well.
In the LLD you need to get away from the idea, that you can depict a device as a single icon, with lines coming out of it. You use those for your HLD. There is so much going on inside and between devices, that you need to make them big. Use icons in the top corner to show what kind of device it is, but make lots of room.
Don't be afraid to put devices inside devices. Use decent sized interfaces, that can contain information. Put interfaces inside interfaces if you need to. Use an interface shape, that clearly shows ingress and egress. When putting devices, interfaces or areas inside each other, think about which element is a part of something bigger.
If you find yourself typing, the same information over and over again, change it to a symbol and put it in the legend.
Use combinations of, color, shading, corners, line types and thickness as symbols.
Don't be afraid to use the space you need. Have you ever seen a blueprint for a house, that fits on a piece of A4?
If your design becomes crowded, you need to group things together and put them in separate diagrams. When you do this, you need to be consistent in your grouping. Make a rule, like: "If there are more than 3 devices doing the same thing connected to another device, they will be grouped."
Here is an overview of what could go into various diagrams and how you can depict it. It's not complete, but from the context your should be able to figure out where, what information goes and how you can depict it.
Layer 1 diagrams should depict everything physical. You want to show how it's wired together. This could contain your:
Devices: Depict the type as a symbol and the name as text. Use a distinct shape for devices, like a rectangle.
Physical interfaces: Media as asymbol and a name text. If you use special MTU, duplex and speed depict that with color and numbers, otherwise put it in the legend.
Cables: Use colors for types and the end of the line colored differently to show subtypes.
Locations: Group things together in their physical location. Use a distinct border shape for locations.
Layer 2 diagrams should depict your domains, regardless of what they travers. The reader should be able to follow a domain everywhere it goes. Inside and outside of devices. The reader also needs to know the transport method of your domain, is it a VLAN, L2 VPN, a (virtual) switch. This could contain your:
Devices: Any device, physical or virtual, see Layer 1.
Interfaces: Physical and logical interfaces, use iconography to represent the type (LAG, redundant ethernet and so on). Place interface on the edge of your device if they interconnect with other devices or on the inside of your device, if they exist only logically there.
VLANs: Inside and outside your devices. Different VLANs can be show by color. If you need to represent both S-VLANs and C-VLANs together, place a thick S-VLAN at the interface and spilt it into several C-VLANs on the interconnecting part. Use a distinct line type for VLANs. You can put the ID either in the legend or in the middle of the line.
Spanning Tree: Interfaces can be marked with different states, either by color or symbols.
MPLS: Isn't techincally layer 2, but is required to represent other layer 2 domains. MPLS can be represented as a virtual device surrounding the MPLS area, with the MPLS interfaces connecting through that area. Use a distinct line type and distinct shading and shape for your area.
L2 Circuits: Can be represented as a virtual device with two interfaces inside the MPLS device described above. You can then interconnect these interfaces with their real interfaces on the physical devices.
L2 VPN: Can be represented in the same way as L2 circuits, as its own device inside the MPLS device, with VLAN representation, just like on physical devices.
Layer 3 diagrams should depict your subnets and only elements participating on the IP layer. The reader should be able to see how to get from one subnet to another. This could contain your
Devices: Only layer 3 devices, logical or physical
Interfaces: Logical and physical, but only layer 3 interfaces.
Subnets: Use cloud or bus depictions. Put the subnet in CIDR format there. The connecting interfaces should only have the remainder of the IP addresses displayed. If you use a bus depiction, place the gateway at the end of the bus or mark it out (in bold) on a cloud depiction.
L3 VPN: Are represented as devices inside the MPLS device described in Layer 2 in the same manner as L2 VPNs.
VRRP: Can be represented as a logical interface without a device. Connect one side to the participating interfaces and the other to the subnet.
DHCP: Put a logical device with your DHCP information containing the appropriate interfaces inside the physical device.
These are the basic three diagrams, that you should always have. In addition, you can create functional diagrams suiting your purposes. Here are some examples.
Security diagrams should depict where and how security is handled. This example assumes you're dealing with a layer 3 firewall, but this can just as easily be applied to a layer 2 firewall. I know NAT is in here, which technically has nothing to do with security and if this is your only "security" element you could include that in the Layer 3 diagram. The diagrams could contain your
Devices: Any device performing a firewall/security function.
Interfaces: Particitpating in a firwall/security function.
Subnets: All subnets affected by a firewall/security function.
Zones: Represent these as colored cones. With the top of the cone placed on the interface creating the zone.
Policies: Create a logical container for policies inside the device. Connect it to the zones with arrowhead indicating the direction of the policy.
Rules: Create a logical container inside your policies or devices. Give it an icon indicating its action and place the affected ports/address in the container. If there is to much information to put here or in the legend, refer to the written documentation.
NAT: Static NAT is represented as a line with arrowheads at each end between the public and private IP addresses. Source NAT is represented as a line with an arrowhead at the NATing address, between the public IP and the subnet. Destination NAT is represented as a line with an arrowhead at the NATed end, between the public and private address/port.
Routing diagrams should tell the reader about the overall routing. What peers and areas exist, how do we get from one area or subnet to another. This could contain your
Devices: Any device performing a routing action, physical or logical.
Interfaces: Any interface participating in a routing action.
BGP: Include all devices inside a colored ASN area. Use lines to represent peerings. iBGP peerings can have the ASN color and eBGP peerings can have two colors representing the ASNs.
OSPF: Include all devices inside a colored OSPF area. Use lines to represent the OSPF neighbors. Use shading to indicate differnt kinds of areas.
Static routes: Put an arrow with the route outside the egress interface.
This is by no means a complete standard and you don't need to do the representations in the way they are described here. If a different representation works better for you, use that instead. I hope it has given you a better understanding of how to do network diagrams and that you have been inspired.
If it sounds like a lot of work, think about why you are doing your documentation.
about all the elements, that make a good solution design
Monday, January 28, 2013
Sunday, January 20, 2013
ISND
That's not a typo in the title. I mean ISND, the International Standard for Network Documentation. You should be familiar with it, but maybe you never heard of it?
This post is about documentation. Documentation can be a lot of things, there's IP documentation, Rack documentation, Network diagrams and so on. Here I'm going to focus on the diagrams, since they are the most common and often the worst kind of documentation.
When I say worst, what I mean is, they are the ones most network architects struggle to produce at a high quality. They are also the ones which are most confusing to read and not always very useful. When you're looking at a network for the first time, you are often thrilled, that someone actually did the documentation, but when you read it, it doesn't contain the information you are looking for or it isn't completely clear, so you end up going through the configuration of the equipment to find out, how it's put together.
Why is that? Why do we struggle to produce good diagrams and why do they rarely meet the needs of the people who read them? The answer is quite simple: There is no standard, there are no guidelines, there are no principles. That's why you never heard of ISND.
I spent a lot of time on Google trying to find something useful. It isn't there. The best I could find, was explanations of the importance of network diagrams and documentation, naming conventions and so on. There is a certain level of agreement on the iconography and that's it. I also never heard of anyone who had a good education on how to draw diagrams. This puzzles me, since it is one of our main tasks to produce good diagrams and read other peoples diagrams.
So I have decided to explain to you how to do good diagrams. Hopefully this will help you if you unsure about how to diagrams or give you some additional inspiration, if you do good diagrams already.
It's not really that difficult. Consider architects for a moment. They produce a lot of drawings. They produce design sketches for clients to look at and they produce technical drawings for the builders who construct the house. When clients look at the sketches they can visualize the new house and when the builders look at the technical drawings they now exactly what to build. They don't get a 10 page report describing how the house should be built, they only get drawings. The sketches can be show to any client, even you and me, and we can visualize the house. The same goes for the technical drawings. They are not specific to any builder. You can give the electrical drawing to any electrician, the plumbing drawings to any plumber and so on.
What you notice, is that there are specific drawings, based on what you want to look at. You can't give the electrical drawing to the plumber or the design sketch to the electrician. They all serve a specific purpose and contain only the information, that is relevant for that purpose. The design sketch has no measurements, nor does it show where the water pipes go.
This is where so many network architects go wrong in their diagrams. They try to cram all the information into one diagram, that will contain everything. This can't be done, you can't read it, it's unclear and you can never fit all information on to the same diagram, since some of it needs to be depicted in different ways.
In the next post I'll explain to you how to apply this knowledge to network diagrams.
This post is about documentation. Documentation can be a lot of things, there's IP documentation, Rack documentation, Network diagrams and so on. Here I'm going to focus on the diagrams, since they are the most common and often the worst kind of documentation.
When I say worst, what I mean is, they are the ones most network architects struggle to produce at a high quality. They are also the ones which are most confusing to read and not always very useful. When you're looking at a network for the first time, you are often thrilled, that someone actually did the documentation, but when you read it, it doesn't contain the information you are looking for or it isn't completely clear, so you end up going through the configuration of the equipment to find out, how it's put together.
Why is that? Why do we struggle to produce good diagrams and why do they rarely meet the needs of the people who read them? The answer is quite simple: There is no standard, there are no guidelines, there are no principles. That's why you never heard of ISND.
I spent a lot of time on Google trying to find something useful. It isn't there. The best I could find, was explanations of the importance of network diagrams and documentation, naming conventions and so on. There is a certain level of agreement on the iconography and that's it. I also never heard of anyone who had a good education on how to draw diagrams. This puzzles me, since it is one of our main tasks to produce good diagrams and read other peoples diagrams.
So I have decided to explain to you how to do good diagrams. Hopefully this will help you if you unsure about how to diagrams or give you some additional inspiration, if you do good diagrams already.
It's not really that difficult. Consider architects for a moment. They produce a lot of drawings. They produce design sketches for clients to look at and they produce technical drawings for the builders who construct the house. When clients look at the sketches they can visualize the new house and when the builders look at the technical drawings they now exactly what to build. They don't get a 10 page report describing how the house should be built, they only get drawings. The sketches can be show to any client, even you and me, and we can visualize the house. The same goes for the technical drawings. They are not specific to any builder. You can give the electrical drawing to any electrician, the plumbing drawings to any plumber and so on.
What you notice, is that there are specific drawings, based on what you want to look at. You can't give the electrical drawing to the plumber or the design sketch to the electrician. They all serve a specific purpose and contain only the information, that is relevant for that purpose. The design sketch has no measurements, nor does it show where the water pipes go.
This is where so many network architects go wrong in their diagrams. They try to cram all the information into one diagram, that will contain everything. This can't be done, you can't read it, it's unclear and you can never fit all information on to the same diagram, since some of it needs to be depicted in different ways.
In the next post I'll explain to you how to apply this knowledge to network diagrams.
Saturday, January 12, 2013
You: A serial number
Where do you start a blog? I've been thinking about this for the past week, I have many topics I would like to talk about, so which one goes first? I settled on starting at the beginning. Education. How we become network engineers, architects and designers.
I spent 6 years at university getting a masters in telecommunication. At the end of it I had acquired many new and interesting skills. Above all others I was an expert at passing exams.
Looking back, I now see, that about 5% of what I learned has been relevant for my working life, And that I actually only use about 1%. That equals about 3,5 months of relevant knowledge and about 3 weeks of useful knowledge.
During that same period I did a lot of IT in my free time. All kinds of stuff, servers, networks, programming. Some of it was at my student job, some was voluntary work, and some was just for fun.
What shocked me, was that when I started my first "real" job, I needed almost all the skills and knowledge I had gained in my free time and hardly any I had gained in my education. Actually, I couldn't have done my job without them. I would have been completely naked, just holding my degree. I remember thinking, I should have done more of that! Some of my friends had and I realized, that they actually knew much more than me and where far better prepared for a "real" job.
So what does my degree prove? It proves I spent a certain amount of time, learning certain subjects and that I can pass certain exams. Full stop.
A certificate is exactly the same. A CCIE [Replace with certification, from your favorite vendor here] proves you spent a certain amount of time, learning certain topics and that you passed a specific exam. Full stop.
A CCIE has little in common with real life. You don't use theoretical knowledge in the field you use practical knowledge. Theoretical knowledge is something you look up, when you need it as Einstein said:"Never memorize something that you can look up". A lab isn't a reflection of reality either. There is no network, that has all equipment from the same vendor, with the newest versions of hardware and software, where you have 1ms between devices and your work isn't service effecting. Dealing with "problems" in a lab environment is not "real". Real problems happen at 4.00 in the morning when you haven't slept, you are hungry, your devices are at least an hours drive apart, your service window ends in 1 hour, in two hours your customers are going online and your colleague will have 5.000 phone calls to deal with if you can't get this router to work.
So whats the deal with certifications? IMHO it's cash cow - not for the people who get certified, but for the vendors providing the certification. They make money on the certification programs, exams, learning materials and they requirer their partners to have certificates and they are churning out evangelists by the thousands, who will market their brand.
It's fueled by partner programs, which only serve to acquire higher discounts and by selling the illusion, that with a CCIE you can get a great job and earn lots of money.
Now you ask: "But don't CCIEs get well paying jobs?" Well, didn't your mother tell you to get a college degree, so you can get a well paying job? Unfortunately, that's not how the World works. A college degree is no guarantee of employment. But the costs of the degree are going up. Why is that? Because everyone is getting a college degree. It's a cash cow for the universities fueled by the false equation "degree = job". It's no longer only the top 10%, who can achieve one - everybody gets one. The same goes for CCIEs. There are about 40.000 CCIEs out there, add in all the top level certifications from other vendors and you probably have over 60.000. And thousands are added to theses numbers every year. Once a CCIE was something special, just like a college degree. That just isn't true anymore.
"What about the well paying jobs then?" Here's the secret: It's the other way around! You get experience and prove that you are worthy of a well paying job. Then you can do a CCIE, if you feel like challenging yourself, your employer requires you to or you need to prove yourself, to someone (maybe yourself?).
After working almost 15 years in this industry, I have come to realize, that the people I prefer to work with are usually autodidact, they have no certificates, no degree, never went to university, but they love what they do. They have a desire to do more, learn more, be better and a they are humble to the fact, that they don't know everything. They are not afraid to ask online and offline about the problems they face. If a new skill is required they will go seek it out and absorb it like a sponge. These are the people you want in your company,
When I do a job interview on the employers side of the table, I don't do a validation of the candidates technical skills. I don't have a checklist saying: OSPF, BGP, MPLS...and so on. I want to know who the persons is, how does he deal with an unexpected situation, does he have a desire to acquire new knowledge, has he been in a similar work environment, does he know how to deal with demanding customers.
I have seen job descriptions, with one requirement only: CCIE. Are you kidding me? Is one CCIE the same as the other, so you can just replace them. I would never apply for a position, that has a requirement list as short as that. Either they don't know what they need or they just need a replacement, Like a switch in network, "This one's broke, we'll just get a new one with a different serial number." What does this tell you about yourself, if you apply for a position like that? Are you just a serial number?
I spent 6 years at university getting a masters in telecommunication. At the end of it I had acquired many new and interesting skills. Above all others I was an expert at passing exams.
Looking back, I now see, that about 5% of what I learned has been relevant for my working life, And that I actually only use about 1%. That equals about 3,5 months of relevant knowledge and about 3 weeks of useful knowledge.
During that same period I did a lot of IT in my free time. All kinds of stuff, servers, networks, programming. Some of it was at my student job, some was voluntary work, and some was just for fun.
What shocked me, was that when I started my first "real" job, I needed almost all the skills and knowledge I had gained in my free time and hardly any I had gained in my education. Actually, I couldn't have done my job without them. I would have been completely naked, just holding my degree. I remember thinking, I should have done more of that! Some of my friends had and I realized, that they actually knew much more than me and where far better prepared for a "real" job.
So what does my degree prove? It proves I spent a certain amount of time, learning certain subjects and that I can pass certain exams. Full stop.
A certificate is exactly the same. A CCIE [Replace with certification, from your favorite vendor here] proves you spent a certain amount of time, learning certain topics and that you passed a specific exam. Full stop.
A CCIE has little in common with real life. You don't use theoretical knowledge in the field you use practical knowledge. Theoretical knowledge is something you look up, when you need it as Einstein said:"Never memorize something that you can look up". A lab isn't a reflection of reality either. There is no network, that has all equipment from the same vendor, with the newest versions of hardware and software, where you have 1ms between devices and your work isn't service effecting. Dealing with "problems" in a lab environment is not "real". Real problems happen at 4.00 in the morning when you haven't slept, you are hungry, your devices are at least an hours drive apart, your service window ends in 1 hour, in two hours your customers are going online and your colleague will have 5.000 phone calls to deal with if you can't get this router to work.
So whats the deal with certifications? IMHO it's cash cow - not for the people who get certified, but for the vendors providing the certification. They make money on the certification programs, exams, learning materials and they requirer their partners to have certificates and they are churning out evangelists by the thousands, who will market their brand.
It's fueled by partner programs, which only serve to acquire higher discounts and by selling the illusion, that with a CCIE you can get a great job and earn lots of money.
Now you ask: "But don't CCIEs get well paying jobs?" Well, didn't your mother tell you to get a college degree, so you can get a well paying job? Unfortunately, that's not how the World works. A college degree is no guarantee of employment. But the costs of the degree are going up. Why is that? Because everyone is getting a college degree. It's a cash cow for the universities fueled by the false equation "degree = job". It's no longer only the top 10%, who can achieve one - everybody gets one. The same goes for CCIEs. There are about 40.000 CCIEs out there, add in all the top level certifications from other vendors and you probably have over 60.000. And thousands are added to theses numbers every year. Once a CCIE was something special, just like a college degree. That just isn't true anymore.
"What about the well paying jobs then?" Here's the secret: It's the other way around! You get experience and prove that you are worthy of a well paying job. Then you can do a CCIE, if you feel like challenging yourself, your employer requires you to or you need to prove yourself, to someone (maybe yourself?).
After working almost 15 years in this industry, I have come to realize, that the people I prefer to work with are usually autodidact, they have no certificates, no degree, never went to university, but they love what they do. They have a desire to do more, learn more, be better and a they are humble to the fact, that they don't know everything. They are not afraid to ask online and offline about the problems they face. If a new skill is required they will go seek it out and absorb it like a sponge. These are the people you want in your company,
When I do a job interview on the employers side of the table, I don't do a validation of the candidates technical skills. I don't have a checklist saying: OSPF, BGP, MPLS...and so on. I want to know who the persons is, how does he deal with an unexpected situation, does he have a desire to acquire new knowledge, has he been in a similar work environment, does he know how to deal with demanding customers.
I have seen job descriptions, with one requirement only: CCIE. Are you kidding me? Is one CCIE the same as the other, so you can just replace them. I would never apply for a position, that has a requirement list as short as that. Either they don't know what they need or they just need a replacement, Like a switch in network, "This one's broke, we'll just get a new one with a different serial number." What does this tell you about yourself, if you apply for a position like that? Are you just a serial number?
Saturday, January 5, 2013
Introduction
Welcome
This is the first post on my brand new blog and I want to welcome everybody who reads this blog about all the elements that make a good solution design. I hope you enjoy it.
Who am I
My name is Marcus Hoff and I'm a network architect. I have worked in the network world for the past 10 years and even longer in the IT world. Mainly my employers have been ISPs but I have also worked for VoIP companies and even had my own business.
I finished my Masters in Telecommunications Engineering in 2003 and have designed networks, security solutions and products for service providers and enterprises of many kinds and sizes ever since.
Why this blog
I read an article saying, that there are 1 million new blogs created every day. So what is the point of being one in a million?
Like most blogs I have something I want to share with you.
Through my work, I have seen the same problems, faced the same decisions and met the same attitude over and over again. Always thinking, that "next time it is different" or "if only things where done my way". But "next time" isn't different and when I actually get it "my way", it doesn't turn out how I imagined. I finally realized, what the problems are and why next time is going to be exactly the same and why dictating the "right way" never turns out they way I imagined.
It's as simple as this: If I think I know the solution, I haven't understood the problem.
I whish I had known this 10 years ago and that's why I want to share this with you. If this can help, just a few of you to think different about how you approach to solution design and give you that "a-ha!" moment, then that will be my tiny contribution to the network world. And if you take the time to write about your experiences, good or bad, it will also make me feel better, knowing what works, and what doesn't.
What this blog is and isn't
This blog is about what the above means in network and solution design. I'll be writing about problems, rather than solutions and how to look at them. I'll be writing about how some solutions actually are the problems. I'll try to show you how to approach the problems, by first being able to identify them.
This isn't a place to look for updates on the newest technologies or a place to find ready-to-use designs or to help with the specific syntax of an implementation. No solution or design I present here will work in your situation, they can be helpful to look at and you can draw inspiration from them, but true solutions only arise organically from understanding the problems.
I welcome any feedback about my posts, good or bad. I love to hear about your experiences, problems and solutions. If there is anything you would like to read about on the blog, please let me know.
This is the first post on my brand new blog and I want to welcome everybody who reads this blog about all the elements that make a good solution design. I hope you enjoy it.
Who am I
My name is Marcus Hoff and I'm a network architect. I have worked in the network world for the past 10 years and even longer in the IT world. Mainly my employers have been ISPs but I have also worked for VoIP companies and even had my own business.
I finished my Masters in Telecommunications Engineering in 2003 and have designed networks, security solutions and products for service providers and enterprises of many kinds and sizes ever since.
Why this blog
I read an article saying, that there are 1 million new blogs created every day. So what is the point of being one in a million?
Like most blogs I have something I want to share with you.
Through my work, I have seen the same problems, faced the same decisions and met the same attitude over and over again. Always thinking, that "next time it is different" or "if only things where done my way". But "next time" isn't different and when I actually get it "my way", it doesn't turn out how I imagined. I finally realized, what the problems are and why next time is going to be exactly the same and why dictating the "right way" never turns out they way I imagined.
It's as simple as this: If I think I know the solution, I haven't understood the problem.
I whish I had known this 10 years ago and that's why I want to share this with you. If this can help, just a few of you to think different about how you approach to solution design and give you that "a-ha!" moment, then that will be my tiny contribution to the network world. And if you take the time to write about your experiences, good or bad, it will also make me feel better, knowing what works, and what doesn't.
What this blog is and isn't
This blog is about what the above means in network and solution design. I'll be writing about problems, rather than solutions and how to look at them. I'll be writing about how some solutions actually are the problems. I'll try to show you how to approach the problems, by first being able to identify them.
This isn't a place to look for updates on the newest technologies or a place to find ready-to-use designs or to help with the specific syntax of an implementation. No solution or design I present here will work in your situation, they can be helpful to look at and you can draw inspiration from them, but true solutions only arise organically from understanding the problems.
I welcome any feedback about my posts, good or bad. I love to hear about your experiences, problems and solutions. If there is anything you would like to read about on the blog, please let me know.
Subscribe to:
Posts (Atom)